Doug, Perhaps "never" was a bit of hyperbole. I've been working with FileMan systems since 1986 and haven't yet needed to repoint on a mass basis that Kevin is talking about. A few bad pointers or inappropriately deleted records are generally fixed with the existing FM tools and a bit of manual poking. But especially with something like the Drug file, if you have 1,000 prescriptions pointing to a specific drug you would not be repointing them to ZZ DELETED DRUG. Kevin had wondered why the function didn't already exist. I think the reason is that it was more effort than anyone felt necessary for the types of problems we normally face. On a related note, the tool that I seem to need way more often is an xref verifier. Something that will process all records and verify that they are indexed properly and then process all cross references and verify that each entry (a) points to a record and (b) points to the correct record. I've written several in the past for specific files and xrefs that I was having trouble with but I never spent the time necessary to make a generic checker.
tjh --------------------------------------------------------------------- "I think it's fairly common for people to get upset about science because they confuse explanation with endorsement." -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Martin Sent: Thursday, November 17, 2005 9:33 AM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] Finding all pointers to bad entries/Re: ?Fileman bug? Tom, In theory, you are correct. Our company supports multiple live hospital and clinic settings where things like this can and do happen. We are often called in after the fact to fix broken pointers. This, unfortunately, is the reality. In a setting where permissions are tightly controlled and monitored, this might never occur. I have yet to see such an ideal setting. Douglas K. Martin, MD Clinical Informatics Associates, Inc. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Holloway, Thomas (EDS) Sent: Thursday, November 17, 2005 9:16 AM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] Finding all pointers to bad entries/Re: ?Fileman bug? Kevin, I think you are beginning to see a part of the reason why the tool that you are seeking doesn't exist. It's not only complicated but may, in the end, require human decision making at each pointer level to decide whether to repoint and, if so, where to repoint. The larger factor, I believe, is that this functionality is not generally needed in a production database. You are starting from scratch, so to speak, but with a set of files that contain data you don't need/want. In a live hospital database they would never be deleting drugs (or other pointed to values) since there is a need to retain historical accuracy. tjh -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Martin Sent: Thursday, November 17, 2005 8:52 AM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] Finding all pointers to bad entries/Re: ?Fileman bug? James is correct that a .01 pointer field could be DINUM'd to something other than the pointer value, though I doubt this practice is very common. The possible exception might be cases where a range of internal record numbers are reserved for a particular purpose and a DINUM might be used to enforce that constraint. Typically, however, DINUM'ing a .01 pointer field is done to insure that the internal record numbers of the file correspond to those of the linked records in the target file. This makes some programmatic tasks a bit easier, but obviously makes the task of repointing much more complex. Note that DINUM'ing to a pointer value is further complicated by the fact that a DINUM'd file could also have pointers to it. Some of these pointers might be DINUM'd as well. So this too becomes a recursive operation. There is also the potential for cyclic references that a recursive algorithm would have to take into account. Douglas K. Martin, MD Clinical Informatics Associates, Inc. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Gray Sent: Wednesday, November 16, 2005 8:05 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Finding all pointers to bad entries/Re: ?Fileman bug? That would be a mistake I think. For a DINUMed file the .01 field is the same as the IEN of the file. If you change the .01 field you break that relationship. Who knows what the effect of that might be? It might not be nice. Technically in a DINUMed file the .01 field and the IEN may not be equal. The IEN is a function based on the .01 field. However, in almost all files I have seen that were DINUMed the IEN was set equal to the .01 field. Jim ----- Original Message ----- From: "Kevin Toppenberg" <[EMAIL PROTECTED]> To: <hardhats-members@lists.sourceforge.net> Sent: Wednesday, November 16, 2005 4:25 PM Subject: Re: [Hardhats-members] Finding all pointers to bad entries/Re: ?Fileman bug? What about just simply changing the bogus pointer to a value that points to a new "ZZDELETED" record. DINUM is still confusing enough for me that I'm not sure if this would cause any special problems. Kevin On 11/16/05, James Gray <[EMAIL PROTECTED]> wrote: > > In most cases of DINUMed pointers to bogus or bad records the record in > the > file with the DINUMed pointer is probably bad also. I have no idea what > Kevin wants to do with them if they exist in his database. In most cases > the record should probably be deleted as well. That assumes there are no > pointers to it. Recursively chasing back pointer is probably necessary. > Clearly if you have a DINUMed pointer pointing to a bogus entry you want > to > delete, you need to either copy the record to a new IEN, delete it, or not > delete the bogus entry in the first place. Otherwise you are going to > have > more hanging pointers. Many of these exceptional situations may be rare > enough to just make a list of them so a human can handle them manually. > Jim > > ----- Original Message ----- > From: Greg Woodhouse > To: hardhats-members@lists.sourceforge.net > Sent: Wednesday, November 16, 2005 12:46 PM > Subject: Re: [Hardhats-members] Finding all pointers to bad entries/Re: > ?Fileman bug? > > > BTW, what do you propose to do with DINUMed pointers (cases where the .01 > field is a pointer to your file)? Do you recursively "chase back" pointer > relationships? Do you ever copy records? > > James Gray <[EMAIL PROTECTED]> wrote: > Kevin, > Where are you on this project of creating code to $Order through all of > the > files that might point to bad entries in file 50? I will try to take a > look > at it if you have not already done what I implied below. > Jim Gray > > > > > > > > > > > > === > Gregory Woodhouse <[EMAIL PROTECTED]> > > > > "Einstein was a giant. He had his head in the clouds and his feet on the > ground." > > -- Richard P. Feynman > > > ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=ick _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
