One of our customers reported a logical file that our QuestView
application could not open (and throws a fatal exception trying). They
sent us a (presumably dummy version of) the logical and its based-on
physical, and I was able to duplicate the problem with no difficulty at all.
It turns out that the logical in question is an SQL INDEX, apparently
from either JDE World or (more likely) E1, and when QuestView digs out
its meta-data, QDBRTVFD returns a large negative number as the
displacement to the join-spec array, and then (not surprisingly) blows
up trying to resolve a pointer to it (I think we only looked it up for
completeness sake, because we're not actually using it!).
Given that we don't actually use the join-spec array, I commented out
the code that attempts to resolve a pointer to it, and sure enough, it
opens . . . to a completely empty file.
I then created an SQL INDEX on one of our files. It opens just fine, so
I did a bit more digging:
When I look at the "problem" index in DSPFD, I notice that:
Maximum members . . . . . . . . . . : MAXMBRS 1
Number of triggers . . . . . . . . : 0
Number of members . . . . . . . . . : 0
and when I look at the database relations for its based-on physical, I
get conflicting results: the "problem" index shows up in DSPDBR, but it
doesn't show up in QuestView's DBR screen (based on the QDBLDBR API).
By contrast, when I look at the index I created, I get:
Maximum members . . . . . . . . . . : MAXMBRS 1
Number of triggers . . . . . . . . : 0
Number of members . . . . . . . . . : 1
and the index shows up just fine in both DSPDBR for the based-on
physical, and in the QuestView DBR screen.
That tells me there's probably something very funky with the "problem"
index. But what would cause an SQL INDEZ to show up as having no
members, and to show up in DSPDBR on the based-on physical, but not in
the QDBLDBR API?
--
JHHL
midrange.com
