From time to time I run into applications that use a character string
to hold multiple values, perhaps a key made up from both an integer and
text string, since Image doesn't provide for concatentated keys.
Another common thing is to find a big buffer of like X100 filled
with all sorts of binary data (packed decimal, integer, etc.)
Sometimes the format of the data is dependent on a record type,
which is easy enough to code in Cobol, but a real pain for use
with ODBC, etc.


Since Cobol can redefine anything, you may find code that moves in something
like an integer account number, followed by a text field, all to a big
field,
then adds that to the data base. It would certainly have been better to
convert
the integer to character and made an all character key, but even this
has problems of its own.

If you have Suprtool, you can dump records in hex and character mode,
much like fcopy. If you use Image and don't have Suprtool, you really,
really should get it. I have decided I won't work anyplace that doesn't have
Suprtool, as it makes life so difficult.

Anytime I suspect anything funny with a data base record, the first thing
I do is dump it with Suprtool, and take a look at the data. In the standard
Suprtool dump, non-printing characters are replaced by a period, so if I see
any unpexected periods, I also dump it in hex and char, and see what
is really going on.

And as Wirt points out, using another tool, such as Query, to do a quick
check
is always a good
thing to do right off. If Query can't access the data chances are your
program will have problems too!

-----Original Message-----
From: Wirt Atmar [mailto:[log in to unmask]]
Sent: Wednesday, December 13, 2000 8:38 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] Image Datatypes X(8) but storing non character
values in data base , why?


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