That’s an interesting bug.  FM should remove the “PT” node.  Using the Check/Fix DD Structure option does clean it up if you select the file(s) previously pointed to.

 

I wonder if the Duplicate Resolution and Merge processes could be used to advantage to address the mass correction of “bad” entries.  Most of the code to efficiently chase down and update all the references is already in place.

 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Martin
Sent: Tuesday, November 15, 2005 12:01 PM
To: [email protected]
Subject: RE: [Hardhats-members] Finding all pointers to bad entries/Re: ?Fileman bug?

 

You need to be a bit careful using the “PT” xref as it can be inaccurate.  Try this:

1)     Create a pointer type field in a file

2)     Look at the “PT” xref in the target (pointed to) file for a reference to the source (pointed from) file.  It should be there.

3)     Change the field datatype to something else (e.g., free text)

4)     Look again at the “PT” xref.  It is still there.

 

You should always verify that the referenced field does indeed point to the expected file by examining its DD entry.

 

Douglas K. Martin, MD

Clinical Informatics Associates, Inc.


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Woodhouse
Sent: Tuesday, November 15, 2005 1:39 PM
To: [email protected]
Subject: Re: [Hardhats-members] Finding all pointers to bad entries/Re: ?Fileman bug?

 

Yes, that's where they're found. I'm not 100% that variable pointers create "PT" nodes, but I believe they do.

James Gray <[EMAIL PROTECTED]> wrote:

Are the
^DD(50,0,"PT",
nodes not a complete list of the files and fields pointing to file 50?

 

 

===
Gregory Woodhouse  <[EMAIL PROTECTED]>

"Einstein was a giant. He had his head in the clouds and his feet on the ground."

-- Richard P. Feynman

 

Reply via email to