third_party_content:community:commentary:forums_nonworks:ce6ea2cfac9382ac852567980065e85d

Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 22 JUN 1999 02:33:06PM Don Miller - C3 Inc. wrote:

We have a client who is having trouble keeping a Relational Index from becomming blank. We have a table (PATIENT) which contains a non-required field PATIENTNO which identifies an alternative ID for another system. The alternative file is PATIENT_XREF which contains 2 fields (beside the key which is PATIENTNO): PAT_ID and LAST_DATE. Our app checks to see if a change in this value would cause the related record in PATIENT_XREF to become Null and deletes the XREF entry if so. The PATIENTNO is Multi-Valued as is the LAST_DATE field. We check to see if the alternative record is in use by a different PATIENT and warn the operator if this is the case. This logic has been working well for a long time. However, at one site we have an instance where the PAT_ID field in the XREF table simply becomes blank. Going into the entry screen and changing the related field to something harmless, saving the record and then putting it back restores the data (usually!!); however, the user has no way of easily detecting th

at this has happened since for new records, there is no entry in the XREF table until save is processed.

This is AREV 2.12 / Novell Netware 4.11. We can't replicate the problem at any other site, but this client has a larger-than-average patient universe (2,000+). By the way, we use this XREF to maintain linkage between our system and several downstream systems so the accuracy of the data is key.

Any Suggestions??

Don Miller

C3 Inc.


At 22 JUN 1999 03:00PM Larry Wilson wrote:

One remote possibility is that, somehow, your field that is relationally indexed has become the *target* of a relational index elsewhere. Edit the dict item and see if it shows being a target.

Probably not, but other than a program wiping it, I can't think of any other cause.


At 23 JUN 1999 09:12AM Don Miller wrote:

I'll check the target option. How can a program wipe it (the target field) since it's protected from write by SI.MFS? You can't write to it with the editor or programmatically (e.g.,

WRITEV "" ON TARGETFILE,KEYID,1)

Don Miller

C3 Inc.

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/ce6ea2cfac9382ac852567980065e85d.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1