Here's a thought (not necessarily a good one): Delete the existing "B" cross-reference and replace it with a new style cross-reference with a set condition so that stub entries will not be indexed.
--- Kevin Toppenberg <[EMAIL PROTECTED]> wrote: > 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 > A practical man is a man who practices the errors of his forefathers. --Benjamin Disraeli ==== Greg Woodhouse [EMAIL PROTECTED] [EMAIL PROTECTED] ------------------------------------------------------- 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
