The UPDATE^DIE call which is the subject of this thread, is a pretty good way to do it. You would use an "@" as the stored value for the ACCESS CODE field ( field #2 on file #200 ).
> Is there a "proper" way to delete the access code from the user to ensure > that the old code gets moved to AOLD? > > > > _____ > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of James > Gray > Sent: Friday, June 24, 2005 10:25 AM > To: hardhats-members@lists.sourceforge.net > Subject: Re: [Hardhats-members] UPDATE^DIE > > > > Don't delete the "A" X-ref. It also applies to all of the existing access > codes. When you delete the access code for a person in file 200 that will > delete the entry for that access code from X-ref A and move it to the "AOLD" > X-ref. > > > > Jim Gray > > ----- Original Message ----- > > From: Theriot, Derek <mailto:[EMAIL PROTECTED]> > > To: hardhats-members@lists.sourceforge.net > <mailto:hardhats-members@lists.sourceforge.net> > > Sent: Friday, June 24, 2005 8:58 AM > > Subject: RE: [Hardhats-members] UPDATE^DIE > > > > Is there a way to delete the scrambled password before deleting the "A" > x-ref? > > -----Original Message----- > From: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] On Behalf Of > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > Sent: Friday, June 24, 2005 9:10 AM > To: hardhats-members@lists.sourceforge.net > <mailto:hardhats-members@lists.sourceforge.net> > Subject: Re: [Hardhats-members] UPDATE^DIE > > The "A" crossref is used to look up a scrambled password, so if you delete > it, then you can't find the record that had that scrambled password. > I would also consider changing the access code stored in the database. > (ie: > ^VA(200,D0,0)=(#.01) NAME [1F] ^ (#1) INITIAL [2F] ^ (#2) ACCESS CODE[3F] > > or $P(^VA(200,DUZ,0),"^",3) > > if you or someone else later want to re-index the field, or answer "all" > at the proper prompt, these "not so old" access codes could come back and > bother you. > > David > > > > > So deleting the "A" x-ref for a "not so old" account is the same as > deleting > > the "AOLD" x-ref for an account that's been logged as "old"? > > > > > > > > _____ > > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] On Behalf Of Cameron > > > Schlehuber > > Sent: Thursday, June 23, 2005 5:02 PM > > To: hardhats-members@lists.sourceforge.net > > Subject: RE: [Hardhats-members] UPDATE^DIE > > > > > > > > Under Manage User File, use the Purge Log of Old Access and Verify Codes > > [XUSERAOLD] (of course, if the person's code hasn't been logged as "old" > > yet, it will still be in the "A" x-ref.) > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> ] On Behalf Of > Theriot, > > Derek > > Sent: Thursday, June 23, 2005 9:54 AM > > To: hardhats-members@lists.sourceforge.net > > Subject: RE: [Hardhats-members] UPDATE^DIE > > > > > > > > That should work. Where can I find it? > > > > Thanks. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > ] On Behalf Of Greg > > Woodhouse > > > > Sent: Thursday, June 23, 2005 11:48 AM > > To: hardhats-members@lists.sourceforge.net > > Subject: RE: [Hardhats-members] UPDATE^DIE > > > > Oh...I see. I think there's an option to purge old access codes. > > > > --- "Theriot, Derek" <[EMAIL PROTECTED]> wrote: > > > > > I don't want to remove the entry from the file, just reuse the Access > > > code. > > > In order to have a unique code for each user, I will need to remove > > > the code > > > being reused from the current owner. The main purpose of this is to > > > keep > > > user ids as consistent as possible. Our users don't like having to > > > remember > > > several login IDs for different applications. > > > > > > In a perfect world in our case it would be great if we could use > > > windows > > > authentication as we do with all of our SQL Server applications, but > > > that's > > > probably asking too much. > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > ] On Behalf Of > > > Greg > > > Woodhouse > > > Sent: Thursday, June 23, 2005 11:04 AM > > > To: hardhats-members@lists.sourceforge.net > > > Subject: RE: [Hardhats-members] UPDATE^DIE > > > > > > Users are disabled in file 200 when they no longer need access to the > > > system, not deleted. Deleting entries in various "core" files like 2 > > > or > > > 200 is generally not feasible (or was deemed not to be), and so VistA > > > applications are designed around the assumption that entries would > > > never be removed from these files. One major issue is referential > > > integrity: try doing a standard DD listing of file 200 to see how > > > many > > > files point to it (or just look at ^DD(200,0,"PT",*)). > > > > > > --- "Theriot, Derek" <[EMAIL PROTECTED]> wrote: > > > > > > > At least I know I wasn't completely on the wrong track. > > > > > > > > > > > > > > > > I've been playing around with this for a while now and I've been > > > able > > > > to > > > > create some entries. Now I am trying to expand it to create access > > > > codes > > > > for the new records. I was using some code posted by Cameron > > > > Schlehuber as > > > > a guide: > > > > > > > > > > > > > > > > ; Generate a unique ACCESS CODE > > > > > > > > F S XUU=$$AC^XUS4 S (X,XUH)=$$EN^XUSHSH(XUU) > > > > Q:'($D(^VA(200,"A",X))!$D(^VA(200,"AOLD",X))) > > > > > > > > S FDA(200,IEN,2)=XUH > > > > > > > > D FILE^DIE("","FDA") > > > > > > > > > > > > > > > > However, I don't want to create a random code. I would like to use > > > a > > > > code > > > > that is equal to that users network ID, which will be in the input > > > > file. > > > > The ID should be unique to that person, but there is one small > > > > problem. As > > > > users come and go in our environment, we reuse old user IDs. Is > > > > there a way > > > > to see if an access code already exists for another user? And if > > > the > > > > code > > > > does exist, remove it from that user so it can be used on the new > > > > record? > > > > > > > > > > > > > > > > All of the "finder" utilities (FIND^DIC) I've found in the > > > > documentation use > > > > the indexes to perform the search. I don't see where Access Code > > > is > > > > an > > > > index by itself on file 200. The only thing I see that is close is > > > > AUSER > > > > which also has the name attached. Unfortunately, I won't know the > > > > old user > > > > of the ID when I'm performing the search. > > > > > > > > > > > > > > > > I would also like to thank everyone for the responses. They've > > > been > > > > very > > > > useful. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Derek > > > > > > > > > > > > > > > > _____ > > > > > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > ] On Behalf Of > > > > Lloyd > > > > Milligan > > > > Sent: Thursday, June 23, 2005 7:41 AM > > > > To: hardhats-members@lists.sourceforge.net > > > > Subject: Re: [Hardhats-members] UPDATE^DIE > > > > > > > > > > > > > > > > Ah. This morning I tested your code and reproduced the "undefined" > > > > error. > > > > However, on namespacing the FDA array the code worked, creating 3 > > > > test > > > > entries. I confess this surprised me but it is what happened--I > > > > repeated > > > > the trial a couple of times. Recommended programming practices for > > > > VistA > > > > are published here http://www.hardhats.org/tools/sac96.html > <http://www.hardhats.org/tools/sac96.html> > > <http://www.hardhats.org/tools/sac96.html > <http://www.hardhats.org/tools/sac96.html> > > > > > <http://www.hardhats.org/tools/sac96.html > <http://www.hardhats.org/tools/sac96.html> > > <http://www.hardhats.org/tools/sac96.html > <http://www.hardhats.org/tools/sac96.html> > > . > > > > > > > > > > > > > > > > Lloyd > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: Lloyd Milligan <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > > > > > > > > To: hardhats-members@lists.sourceforge.net > > > > <mailto:hardhats-members@lists.sourceforge.net > <mailto:hardhats-members@lists.sourceforge.net> > > <mailto:hardhats-members@lists.sourceforge.net > <mailto:hardhats-members@lists.sourceforge.net> > > > > > > > > > > Sent: Wednesday, June 22, 2005 12:17 PM > > > > > > > > Subject: Re: [Hardhats-members] UPDATE^DIE > > > > > > > > > > > > > > > > The symbol table contents at the point of error (P, XUIEN, etc.) > > > > suggest the > > > > immediate cause may relate to the IENS. Try "+1," to create a > > > single > > > > new > > > > entry. > > > > > > > > > > > > > > > > I am not accustomed to reading Cache Object Script. It doesn't > > > look > > > > right > > > > to NEW variables inside a loop. Plus the variable U is sacred in > > > > VistA. > > > > Etc. Perhaps it would be helpful to study the ^XUSERBLK code as a > > > > general > > > > model for creating File 200 entries automatically.. > > > > > > > > > > > > > > > > Lloyd > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: Theriot, Derek <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > > > > > > > > To: hardhats-members@lists.sourceforge.net > > > > <mailto:hardhats-members@lists.sourceforge.net > <mailto:hardhats-members@lists.sourceforge.net> > > <mailto:hardhats-members@lists.sourceforge.net > <mailto:hardhats-members@lists.sourceforge.net> > > > > > > > > > > Sent: Wednesday, June 22, 2005 9:40 AM > > > > > > > > Subject: RE: [Hardhats-members] UPDATE^DIE > > > > > > > > > > > > > > > > I did notice the problem with DIC(0) and it is set in my code. I > > > am > > > > only > > > > trying to load a few fields at this time to keep it as simple as > > > > possible. > > > > I have attached the code I am running and some output from the > > > > execution, > > > > including variables and their values. > > > > > > > > > > > > > > > > > > > > _____ > > > > > > > > > > > > From: [EMAIL PROTECTED] > > > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > > > > > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > ] On Behalf Of > > > > Lloyd > > > > Milligan > > > > Sent: Tuesday, June 21, 2005 8:04 PM > > > > To: hardhats-members@lists.sourceforge.net > > > > Subject: Re: [Hardhats-members] UPDATE^DIE > > > > > > > > > > > > > > > > Evidently mine is a minority opinion, but I think it is OK, even > > > > commendable, to use UPDATE^DIE to pre-load File 200. In fact, > > > > ^XUSERBLK > > > > "Grant Access by Profile" constructs an FDA and calls UPDATE^DIE, > > > so > > > > what > > > > can be wrong with that? > > > > > > > > > > > > > > > > I know of a bug in one of the File 200 cross-references at > > > > LAYGO^XUA4A7, > > > > where it assumed that DIC(0) exists--That one is easily > > > circumvented > > > > by > > > > setting DIC(0) in your code. Possibly similar problems exist in > > > > other > > > > indexes, but I doubt this has relevance to the error you observed. > > > > > > > > > > > > > > > > To troubleshoot I would suggest constructing a minimal FDA and then > > > > calling > > > > UPDATE^DIE to create a single entry. You don't show the value of > > > key > > > > variables at the point of error, or the code used to construct the > > > > FDA or > > > > IENS. Therefore, it is difficult to make a constructive > > > suggestion. > > > > > > > > > > > > > > > > Lloyd > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: Theriot, Derek <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > > > > > > > > To: hardhats-members@lists.sourceforge.net > > > > <mailto:hardhats-members@lists.sourceforge.net > <mailto:hardhats-members@lists.sourceforge.net> > > <mailto:hardhats-members@lists.sourceforge.net > <mailto:hardhats-members@lists.sourceforge.net> > > > > > > > > > > Sent: Tuesday, June 21, 2005 5:10 PM > > > > > > > > Subject: RE: [Hardhats-members] UPDATE^DIE > > > > > > > > > > > > > > > > I am very new at this so I'm not sure what you mean by building the > > > > entries > > > > incrementally. Do you mean inserting the data straight into the > > > > globals? I > > > > was hoping to use UPDATE^DIE since it does all of the > > > indexing...(at > > > > least > > > > that's what the documentation says). > > > > > > > > Anyway, can you provide me with a starting point and maybe a short > > > > summary > > > > of what would be involved. > > > > > > > > What I am trying to do is populate file 200 with data from our > > > Doctor > > > > Master > > > > file. Since I work for a large university with several hospitals, > > > we > > > > have a > > > > few thousand doctors that would need to be entered. > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > > > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > ] On Behalf > > > Of > > > > Greg > > > > Woodhouse > > > > > > > > Sent: Tuesday, June 21, 2005 4:03 PM > > > > To: hardhats-members@lists.sourceforge.net > > > > Subject: Re: [Hardhats-members] UPDATE^DIE > > > > > > > > There are a few files like 2 and 200 that have so much logic built > > > > into > > > > the DD (try looking at a standard listing) that doing bulk updates > > > > like > > > > this is all but a lost cause. You can try tracking it down, but > > > most > > > > likely you'll have to build your entries incrementally, following > > > the > > > > > > > > logic in the Registration module, or something similar. > > > > > > > > (Editorial aside: I don't think things have to be that way, they > > > just > > > > > > > > are.) > > > > > > > > --- "Theriot, Derek" <[EMAIL PROTECTED]> wrote: > > > > > > > > > I am trying to populate the NEW PERSON file by reading a text > > > file > > > > I > > > > > received from an existing application. I have written a routine > > > > that > > > > > will > > > > > read the file and create the FDA array. However when it gets to > > > > the > > > > > UPDATE^DIE call, I get the following message: > > > > > > > > > > > > > > > > > > > > . S [EMAIL PROTECTED]@($TR(P,"+?")) > > > > > > > > > > ^ > > > > > > > > > > <UNDEFINED>ADDCONV+5^DIEF1 > > > > > > > > > > > > > > > > > > > > I am only trying to load a few fields for now just to try to get > > > it > > > > > > > > > working. > > > > > I think I have the required fields covered (NAME, > > > SERVICE/SECTION). > > > > > > > > > Is > > > > > there something I'm missing? Does anyone have a better > > > suggestion > > > > > for > > > > > accomplishing this? > > > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members