RE: NULL's on the Iseries

>I also saw that this API is intended for migration from other databases

>(iSeries, e.g.?) and is going away, and MS encourages people to use
things 
>like ADO or ODBC.

The concept of embedded SQL is not one that MS likes. It requires the
compiler (or at least a "pre compiler)" to understand both the language
being compiled and the database you're trying to talk to -- fine if
you're looking at RPG on iSeries, but not nice if you're looking at
supporting a wide range of databases from a wide range of languages. MS
definitely pushes you to ADO, but ADO can talk to just about any
database (incl. iSeries) and even lots of things that aren't databases
(Excel, ActiveDirectory, WMI, etc.)

>I did not find how one tests for the NULL attribute in a column after 
>fetching it in SQL Server.

You won't find that in the SQL Server manuals -- it depends on the
language you're using, unless you're speaking in T-SQL in a stored proc,
where you can simply compare a field to null (if RetirementDate = null)

>I do wonder if some of the SQL problems are not coming from SQL itself,
not 
>RPG. Maybe? 

A little of both perhaps? Part of the problem w/nulls is that they
represent a value that states "there is no value". So, how do you store
that in a simple type? Take a character field, or a numeric, or an
integer, or any other type we're used to in RPG, what value would you
store in that field to indicate a null? There isn't one. For example,
take a 1 byte character field. You can _validly_ store any value in that
field from x'00' to x'ff', there's nothing left, hence you need some
other way of representing nulls, the RPG uses the null indicator array.

-Walden

------------
Walden H Leverich III
Tech Software
(516) 627-3800 x11
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)