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 -----

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

Reply via email to