On 8/27/13 11:57 AM, rob@xxxxxxxxx wrote:

Are you saying Qdbfoj "Offset from the start of the FDT header, Qdb_Qdbfh,
to the join specifications, Qdbfj." of
Logical File Specific Attributes (Qdb_Qdbflogl) is returning a large
negative number?

"QDBFJSAO, Offset from the start of the FDT header, Qdb_Qdbfh, to the join specification array, Qdb_Qdbfjfld" is what's returning a large negative number.

We've never seen, or even heard of this happening before, but as it turns out, we're not actually using the join specification array, and so we evidently only resolved a pointer to it because at the time (a somewhat rushed job of converting QuestView from its original hack-based meta-data retrieval to use supported APIs for meta-data retrieval), we were resolving everything in sight, on the off-chance that it might be useful.

We've also been informed that the production version of the file, the one that's crashing QuestView for the customer, isn't missing its member, which suggests that the problem only appeared when they made our dummy version of the database.

I also note that when I do an SQL CREATE INDEX to build a new index, theoretically identical to F0111_1, the resulting index doesn't have the problem.

Here's something weird: while doing the above (and inspecting another F0111/F0111_1 that are perfectly healthy), I happened to notice that F0111_1 has exactly the same keys as F0111, and doesn't appear to have any selects or omits. Why would anybody bother creating an index that's keyed exactly the same as the table? It seems rather redundant.


This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page