Jim Gray
----- Original Message ----- From: "Kevin Toppenberg" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, April 05, 2005 10:34 AM
Subject: Re: [Hardhats-members] Fileman drop-out on pointer update
Well, the long and the short of it is that I should NOT have tried to kill one of the two duplicate records. Thus I am doing something not supported, so a crash is not technically a bug/problem. ("You put your fingers into the spinning gears, you have to put up with getting pinched!")
So I am going to read up (all 200 pages in the manual) on how to merge patients.
I sure hope that as I blunder my way to a better understanding that I don't do something really bad....
Kevin
--- James Gray <[EMAIL PROTECTED]> wrote:
--------------------------------------------------------------------------------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: [email protected]
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: [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
=== message truncated ===
__________________________________ Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. http://www.advision.webevents.yahoo.com/emoticontest
-------------------------------------------------------
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
------------------------------------------------------- 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
