×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 8/27/13 11:57 AM, rob@xxxxxxxxx wrote:
James,
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.
--
JHHL
midrange.com
