> -----Original Message-----
> From: Richard Sheehan
>
> Does anyone know of any undesirable side effects of storing
> the acsii(0)
> NUL in a field in an Image Dataset?  And for the ?inevitable? future,

Since the IMAGE intrinsics know the length of the item(s) being stored in a
given set, there are no problems from the database's side of things
regarding the contents -- in fact, the field definitions if X, I, P, etc.,
don't have any real bearing on the actual contents of those fields -- bits
are bits...

The part of the system that DOES care about field types is QUERY -- Query
will attempt to convert a (potentially) binary value into something
displayable for reports or take ascii-character data in and convert to the
underlying field type when inserting it into the database.  QUERY will
report a field as having a "null" value IF the first byte of a NON-NUMERIC
field is a null, but that is a query-specific behaviour and not an aspect of
the database itself.

Finally, if you think about it, since one of the legal "types" is "I", or
"Integer", sized in 2 or 4-byte sizes, values such as "143" will have at
least ONE byte of binary zeroes (null) when stored in the database.

> how about any other DB's for that matter?

Databases implemented in languages such as C *might* have a problem with a
null-byte in the middle of the data, but that depends upon whether they use
the "standard" string library routines for data (buffer) handling or if they
use the "memxxx()" versions where explicit lengths are required.

The caveat to all this is actually that last paragraph: if you ACCESS the
database using languages that treat the ascii NULL as an end-of-string
indicator, then you might have difficulty with embedded NULLS, but that's an
application problem, not a problem with the database itself...

Tom Emerson

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *