Re: [Hardhats-members] Fileman drop-out on pointer update

[James Gray]

I am not in a situation where I can look at the DD's for file 2 and file 9000001 so I am not sure about the nodes that are causing the problem.  I do not see how not having the $G is what could have caused the situation of not having the ^DPT entry.  I would like to see how having the $G would have allowed the data to update correctly.  In principle there are better ways of writing code than to allow M errors to detect corrupt data, but merely preventing the M error may also allow the code to do things that will further corrupt the data as well.  Either way is a risk.   The VA uses a X-ref on the SSN field to keep files 2 and 9000001 in synch.  Normally it works well.  It does assume that the SSN field is required.  You can get into trouble if you make the SSN field optional.  IHS keeps the two files in synch via code in the special Fileman lookup routine on file 2.  That way they get around the problem of SSN being not a required field.   Jim Gray ----- Original Message ----- From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Monday, April 04, 2005 12:45 PM 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 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)) > > > > GTM>w DIS(0) > > S Y=D0 I $D(^AUPNPAT(Y,0)) X "I > '$P(^DPT(Y,0),U,19)" W > > $E(^AUPNPAT(Y,0),0) > > GTM>w Y > > 75002 > > GTM> > > > > It looks like the "^DPT(Y,0)" ought to be > > "$G(^DPT(Y,0))" > > > > Kevin > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam?  Yahoo! Mail has the best spam > protection around > > http://mail.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 >   __________________________________ 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