What data should such a stub contain? Kevin
--- Cameron Schlehuber <[EMAIL PROTECTED]> wrote: > After a "merge" of patient data, a "stub" is left > behind. > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Marianne > Susaanti Follingstad > Sent: Monday, April 04, 2005 11:46 AM > To: [email protected] > Subject: Re: [Hardhats-members] Fileman drop-out on > pointer update > > > > What then do you suggest? In this case, NOT having > the $G is what created > the situation of NOT having a ^DPT entry that is > pointed to. In other > words, if the $G had been there, the data would have > updated correctly and > avoided the data integrity problem that now exists. > There has to be better > ways to detect missing or corrupt data than having > an application crash, > which risks further corruption of more data. > > I'm curious as to what the VA does for duplicate > records; anyone know? If > there is a merge capability or deletion and > repointing of duplicates and it > uses the standard FileMan functionality, then it too > could have the same > issue. > > In this instance, the file on which things blew was > an IHS Patient file, so > maybe the VA avoided such pitfalls. It is > interesting to note that the SCR > node (which is meant to screen entries) is also > being used here to display > info, which does not seem like a great idea; > however, there could still be > valid reasons to need to look at info in a pointed > to file during a > screening. > > Marianne > > James Gray wrote: > > One could argue that it is not fine to put the $G > there. There should never > be a case in a good database that ^AUPNPAT(Y,0) > exists and ^DPT(Y,0) does > not exist. If that happens something is wrong in > your database and it needs > to be cleaned up. I have seen ^AUPNPAT(Y,0) nodes > exist when the > corresponding ^DPT(Y,0) nodes did not exist on a > system running Cache just > for the record. If you put the $G in you may never > know that you have a bad > node and who knows what else that bad node may do? > I would suggest not > putting in the $G. Jim Gray > > ----- Original Message ----- > > From: Marianne <mailto:[EMAIL PROTECTED]> > Susaanti Follingstad > > To: [email protected] > > Sent: Saturday, April 02, 2005 11:08 AM > > Subject: Re: [Hardhats-members] Fileman drop-out on > pointer update > > It should be fine to put the $G in there. There > can't be any unforeseen > consequences to having it there. In fact, as you > found, there are > unforeseen consequences to NOT having it there. As > I mentioned, it would be > good to have someone review these SCR nodes to see > if there are any other > potential problems. > > Marianne Follingstad > 301 251 0139 > > Kevin Toppenberg wrote: > > Marianne, > > Thanks for your help. > > Following your instructions: > GTM>zwr ^AUPNPAT(0) > ^AUPNPAT(0)="PATIENT/IHS^9000001sIP^14861^1510" > > GTM>zwr ^DD(9000001,0,"SCR") > ^DD(9000001,0,"SCR")="X ""I '$P(^DPT(Y,0),U,19)"" W > $E(^AUPNPAT(Y,0),0)" > > > So you are right. This is the source of the line > that > caused the drop-out. > > I had suggested: It looks like the "^DPT(Y,0)" ought > > to be "$G(^DPT(Y,0))" > > So I could put that change here. But I'm note sure > if > that would have other unforseen consequenses. > > Is this really a 'bug'? Or is it one of those funny > > database-needs-to-be-rundown type situations? > > Thanks > Kevin > > --- Marianne Susaanti Follingstad > <[EMAIL PROTECTED]> wrote: > > > A quick look at the DI* routines I have (which are > > > old), leads me to suggest that > > you look at the DD for the file defining ^AUPNPAT. > > > Look at ^AUPNPAT(0) to find the > > file number and then look at ^DD(file > > number,0,"SCR") and I'm guessing you'll find > > the culprit there as "I '$P(^DPT(Y,0),U,19)". If > > that is the problem then someone > > should review the "SCR" nodes to ensure there are > no > > similar problems lurking... > > > > Of course the other problem is how to restart the > > process, and unfortunately I don't > > have any suggestions on that issue. > > > > Marianne Follingstad > > 301 251 0139 > > > > Kevin Toppenberg wrote: > > > > > I had two patients that were duplicates--i.e. > the > > same > > > person, but with two different married names. > > > > > > So I deleted one, and told fileman to change all > > > > pointers from the former to the later. > > > > > > (I had to take off a guard to do this) > > > > > > It then scans through all the appropriate places > > > and > > > changes the pointers. > > > > > > But then it drops out after about 20-30 files. > I > > > never knew what was happening before, but I have > > > > recently studied a bit on GTM debugging > > techniques, > > > and here is what I have come up with: > > > > > > Screen log: > > > > > > ROES ELIGIBILITY CONFIRMATION entries whose > > 'PATIENT' > > > pointers have been changed > > > > MAR > > > 29,2005 20:12 PAGE 1 > > > > > > ---------------------------------------------------------------------------- > ---- > > > > > > *** NO RECORDS TO PRINT *** > > > GTM>w $ECODE <---- notice > > drop-out > > > ,M7,Z150372994, > > > GTM>w $ZSTATUS > > > 150372994,SCR+1^DIO2,%GTM-E-GVUNDEF, Global > > variable > > > undefined: ^DPT(75002,0) > > > GTM>zprint SCR+1^DIO2 > > > X DIS(0) Q:'$T G PASS:'$D(DIS(1)) > === message truncated === __________________________________ Do you Yahoo!? Yahoo! Personals - Better first dates. More second dates. http://personals.yahoo.com ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
