Anyway, I just looked at this more closely and there is another issue we haven't addressed yet. I still maintain that the $G is the correct way to go (and checked out that it would not abend with that in there in this situation) for most situations. Unfortunately, there is another wrinkle here, since these are files that are being kept in sync with the IEN being the same for the ^DPT and ^AUPNPAT. In that case, repointing won't be appropriate and FileMan didn't notice that for some reason. I'm guessing that the DD(9000001,.01,0) for the ^AUPNPAT file has code that sets DINUM or it is set by software. I just tried a similar exercise (with a $G in place) and FileMan beeped at the attempt to change the pointer, thus there was a dangling pointer left in place, which is also not desireable. Neither a crash nor this is optimal, so I hope the merge software deals with things more throughly and deals with such insync files. [So easy to be a Tuesday night quarterback ;-)]
Meanwhile, I am somewhat puzzled by the seeming lack of the SCR node I set up to have any effect during lookups (only during repointing), and yes, I did add "s" to the 0 node of the file. Sigh...
Marianne
Kevin Toppenberg wrote:
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
