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
