Jim Phillips writes:

>>> Therm-O-Link <[log in to unmask]> 12/15/97
09:43am >>>
Jerry Fochtman replies:

>When QUERY detects the item is type 'Z' and the FIND value is
>positive, it actually performs 2 DBFINDs; one signed and one
>unsigned.....

Yeah, I can see that's what it is doing.  My original question
still stands: Why?

And furthermore, the more I think about this, the more the real
problem seems to be SQL's inability to handle unsigned integers
in the Z-type data items.  I mean, the problem never surfaced
until we started updating the data set via ODBC and SQL, then
all these "wierd" characters started appearing in the data.

So, perhaps it's the SQL interface to Image, or the ODBCLine/SE
product that's causing these problems.  I have good information
that the problem is the SQL interface to Image, and has been
for some time (like since SQL was first interfaced to Image).
I have also been told that HP refuses to even consider a fix
for this.

The end of all this is BEWARE!  If you're using Z-type data items
as unsigned numbers, you can prepare yourself to convert all your
data and programs and copylib's to handle signed numbers if you
decide to use SQL or and ODBC product which requires SQL.
--------------------------------------------------------------------------------------
All this is quite true about Z-type and Image/sql, though it is not really the
fault of Image/Sql and certainly not with anybody's ODBC.  You can
screw up the data just as easy with ISQL.  That's because SQL does not
support the concept of an unsigned numeric field, whether decimal,
integer or float.  However what you can do is have SQL treat your Z
field as a char field by using the UPDATE TYPE command in Image/Sql to
map the field from say Z4 to X4.  This will eliminate the sign problem on
inserts and updates, but not screw up your COBOL applications which
still have a PIC 9(4) definition.  Of course you will not be able to use
these fields in arithmetic operations in SQL, and must enter all leading
zeros, but this may be sufficient for your PC apps.

By the way, the same problem of DBFIND not finding all records signed
and unsigned,  and putting in a sign with SQL also affects 'P'acked type
items.  Unsigned 117 is not the same as +117.

Mike Berkowitz
Guess? Inc.