Ken Born writes:

> Thanks for your advice.  You brought up a couple good points.  I do not want
>  to change the schema of the database because of the issue of re-compiling
>  the code and the unexpected results the programs might generate.  I do
>  believe the field is a search field and it only worked in Transact with a
X8
>  field defined in the database.  So, that leaves IMAGE/SQL mapping.  I'll
>  check into that.  That would be nice.

Let me say that I think everyone may be making this problem too complicated.
There are two programs that come with every HP3000 that, to me, represent the
"gold standard" when it comes to seeing what you are truly dealing with.

One of these programs is FCOPY. When used with the CHAR and HEX options, you
can see what is really in your files. Indeed, it's the only program I trust
for this function. Essentially every other program you're likely to use is
likely to interpret the data in some manner and present you with a false
picture of what you're seeing. If you need to see what's actually in your
files, you want to use FCOPY.

The second program is Query. While Query does interpret the data in a way
that FCOPY does not, that interpretation is necessary for you to see if your
database's internal root file matches the actual file structure you believe
you have. Nonetheless, Query represents the absolute simplest possible
interpretation. It imposes no other structure or remapping on the data.

If you examine your database using Query and your data is not what you
expected, then your database is corrupted. No amount of remapping is going to
fix anything. [The only exception to that statement is when people do
"tricky" things such as load an X120 field up with binary data and later
interpret it as 10P12 data in the application. That field's data may "look"
corrupted, but it's not. I do however have a few adjectives remaining for
people who do that kind of thing, however :-)] But your issue is a key field,
and virtually no one ever screws around with the representations of that data.

If, on the other hand, Query reads the data in your database correctly, then
you merely have a dictionary problem. There is some intermediary
library/database/dictionary that is providing your application program with
misinformation on how to parse the data it's finding in the dataset.

IMAGE has its own internal dictionary. It's called the root file -- and it is
the standard against which you must decide whether or not your database's
entries are corrupt or not, and Query is the tool to use in that
circumstance. Query reads the root file only. It pays no attention to any
other form of dictionary. And because of that attribute, you can determine
immediately whether your problem lies in the database itself or in your
applications' dictionaries.

Wirt Atmar