There may not be such a need. I would have to check to verify this. But I
believe that ^DIC may check for the archive flag and filter out those
records automatically. I have not actually looked at all of this routine to
see if that indeed is what it is doing. But on the surface, it appears to
be:
DIC3+2 ;Per VHA Directive 10-93-142, this routine should not be
modified.
MN+6 I
D="B",'DZ,'$D(DO("SCR")),$L(DIX)<30,'$D(DIC("S")),'$D(@(DIC_"Y,-9)
")),'$G(DINDEX("OLDSUB")) D ADDKEY I 1 Q
S+1 I $D(@(DIC_"Y,0)")),'$D(^(-9)) S DIY=$P(^(0),U)
----- Original Message -----
From: "Greg Woodhouse" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, April 05, 2005 3:42 PM
Subject: Re: [Hardhats-members] Fileman drop-out on pointer update
> 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
-------------------------------------------------------
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
