|
The code that keeps the two files in synch in IHS
code is in a cross reference on the SSN field. The code that keeps the two
files in synch in IHS code is in the special fileman lookup routine on file
2. In IHS code that is in the ^AUPNLK* routines.
Jim Gray
----- Original Message -----
Sent: Tuesday, April 05, 2005 4:35
PM
Subject: Re: [Hardhats-members] Fileman
drop-out on pointer update
Did you kill it or have FileMan kill it? If FileMan
did it, then I don't think you did anything 'not supported'.
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
|
