Jim Gray
----- Original Message ----- From: "Kevin Toppenberg" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, April 05, 2005 11:26 AM
Subject: Re: [Hardhats-members] Fileman drop-out on pointer update
That is what we have had to do with our old system. And it is an ugly kludge. I was hoping to not have to do that.
As programmers, can't we overcome such a thing.
I don't know yet if vista will show the "stub" entry that is left behind. I hope not.
Kevin
--- James Gray <[EMAIL PROTECTED]> wrote:
When I worked in both the VA and in IHS we did not try to delete bad patient records that showed up in the database. Instead we ZZ'd them by putting the letters ZZ at the beginning of the name. It is an ugly kludge, but it prevents big problems. 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:
=== message truncated ===
__________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250
-------------------------------------------------------
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
