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] 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> .
>
>
>
> Lloyd
>
>
>
> ----- Original Message -----
>
> From: Lloyd Milligan <mailto:[EMAIL PROTECTED]>
>
> To: 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]>
>
> To: 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] 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]>
>
> To: 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]> ] 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.
> >
> >
> >
> >
> >
> >
>
>
>
> "The most profound technologies are those that disappear."
> --Mark Weiser
>
> ====
> Greg Woodhouse
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
>
>
>
>
>
> -------------------------------------------------------
> 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
> <http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click>
> &alloc_id=16492&op=click
> _______________________________________________
> Hardhats-members mailing list
> Hardhats-members@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hardhats-members
> <https://lists.sourceforge.net/lists/listinfo/hardhats-members>
>
>
"The most profound technologies are those that disappear."
--Mark Weiser
====
Greg Woodhouse
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-------------------------------------------------------
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
