>From page 78 at www.va.gov/vdl/VistA_Lib/Infrastructure/Dupl_Rec_Merge/xt_73_p23_um.doc
After the merge completes the FROM record is deleted. A stub record containing only the .01 field and a -9 node is then inserted in the PATIENT file (#2). The -9 node has a value equal to the internal entry number of the TO entry. If anyone tries to access the FROM entry while the merge is in progress, or any time after that, the expected value will be returned without an undefined error. Additionally, the Name and the Social Security Number fields originally contained in the FROM record are moved into the ALIAS subfile in the TO record. (The PDF version of the user manual seems to be corrupted.) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Toppenberg Sent: Monday, April 04, 2005 12:32 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] Fileman drop-out on pointer update 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: hardhats-members@lists.sourceforge.net > 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: hardhats-members@lists.sourceforge.net > > 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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- 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_ide95&alloc_id396&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
