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
