Problems with Fileman new-style cross references.

[Kevin Toppenberg]

I previously posted (https://groups.google.com/g/hardhats/c/6ZpFpr7mlLk) about creating a new-style cross reference.

I seem to be having problems with it not being updated.  All of my filing events occur through regular Fileman API's  (i.e. FILE^DIE), but the index is not being updated.

For example.

yottadb>ZWR ^TMG(22709.1,"C","KMPD",*)
^TMG(22709.1,"C","KMPD",0,0,0,1,192,11,2)=""
^TMG(22709.1,"C","KMPD",0,0,0,1,192,12,2)=""
^TMG(22709.1,"C","KMPD",0,0,0,1,193,16,2)=""
^TMG(22709.1,"C","KMPD",0,0,0,1,686,1215,2)=""
^TMG(22709.1,"C","KMPD",3,0,0,1,190,7,1)=""
^TMG(22709.1,"C","KMPD",3,1,2,1,190,10,1)=""
^TMG(22709.1,"C","KMPD",3,2,3,1,190,11,1)=""
^TMG(22709.1,"C","KMPD",3,2,3,1,192,11,2)=""
^TMG(22709.1,"C","KMPD",3,2,3,1,192,12,2)=""
^TMG(22709.1,"C","KMPD",3,2,3,1,193,16,2)=""
^TMG(22709.1,"C","KMPD",3,2,3,1,686,781,2)=""
^TMG(22709.1,"C","KMPD",3,2,3,1,686,1215,2)=""

Here I manually told Fileman (in another terminal window) to re-index the cross references

yottadb>ZWR ^TMG(22709.1,"C","KMPD",*)
^TMG(22709.1,"C","KMPD",3,0,0,1,190,7,1)=""
^TMG(22709.1,"C","KMPD",3,1,2,1,190,10,1)=""
^TMG(22709.1,"C","KMPD",3,2,3,1,190,11,1)=""
^TMG(22709.1,"C","KMPD",3,2,3,1,192,11,2)=""
^TMG(22709.1,"C","KMPD",3,2,3,1,192,12,2)=""
^TMG(22709.1,"C","KMPD",3,2,3,1,193,16,2)=""
^TMG(22709.1,"C","KMPD",3,2,3,1,686,781,2)=""
^TMG(22709.1,"C","KMPD",3,2,3,1,686,1215,2)=""

Notice that the elements shown in yellow in the first list are not present in the cross reference after manually re-indexing.

Any ideas how to start tracking the problem down?

Kevin

[Sam Habiel]

Debugger, pen, paper. Here's a diagram of the calls (courtesy of George T).

Find the code in DIKC and DIEF and put a break point.

Almost almost certainly a field is empty and the cross reference is not getting called because one of the fields is empty.

--
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

---
You received this message because you are subscribed to the Google Groups "Hardhats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hardhats+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/58b0b3dd-e7f9-4c89-b5d3-0430dd26eb93n%40googlegroups.com.

[Kevin Toppenberg]

Sam,

Thanks you for your reply.  I agree with you that this is likely related to having a null value.  However, we are using a new-style cross reference.  And we have our elements force any null value to be 0.  That is why I can manually force a re-index, and it works.   It just must be that Fileman is not even trying to use the XRef if it finds a null value.  I.e. a inappropriate short circuit of the issue.

If I find this to be the case, would there be any interest in changing Fileman's behavior in this particular case?

Alternatively, would there be a better way to manage this issue?

As a summary, I have records like this

PATCH INFO

  .01 -  PACKAGE="KMPD"

  .02 - VERSION="2.0"

  .03 - PATCH#=1

  .04 - SEQ#=""   <--- NO DATA AVAILABLE

It seems it should be that when any of these 4 values is changed, that the XRef has an opportunity to update. 

I understand that a mumps subscript can't be null (""), thus I understand why Fileman may not be trying.  But a better solution would be to let the computed / new-style XRef run and see the end result, and only abort if the final result includes null.

I guess I don't want to find the exact point of this issue if it is not fixable.

Kevin

[Sam Habiel]

It sounds like the re-xref is the buggy part. It should NOT honor the forcing the empty elements to zero. The correct canonical behavior is that if it's null, don't cross ref.

Just remove SEQ NO from the xref, problem solved. XREF's were never intended to actually store data. Only locate it.

--Sam

To view this discussion on the web visit https://groups.google.com/d/msgid/hardhats/30b4fff4-8189-4978-98de-2ba50d6c5a0fn%40googlegroups.com.

[Kevin Toppenberg]

Hmmm.....  I'm not sure I agree with you.  What is the point of having a 4-fold composite index if I can't rely on it to be always present, and not sometimes absent? But it is what it is, and I'm sure you are right that you are describing canonical behavior.

I'll have to figure a work around.    I think I will change my code so that, when storing the data in the first place, I write out all ""'s as 0's.

Thanks

Kevin