RE: NULL's on the Iseries

Yeah, it was curious to see the MS documentation that sounded as if I were 
reading an iSeries manual. Even explicit mention of a precompiler!

I looked at the info on FETCH in T-SQL - it does not include any syntax for a 
null indicator array or variable.

A little clarification - you say that "they represent a value" - I think that 
NULL actually represent a condition or attribute. As you say, there is nowhere 
in an actual value to put it. IBM has chosen to implement this aspect of 
database technology by adding a bit-array, invisible unless you know where to 
dig in SST, one bit (not byte) for each field (column) in the record (row). 
This appears near the begininng of the internal storage of the data, after the 
so-called DENT byte, which holds the deleted status of the record. The region 
that holds the NULL info also can hold a pointer to the additional segment 
where variable-length data is held. The NULL attribute array can be up to 1000 
extra bytes (8000-field maximum / 8 bits-per-byte). All this is part of 
overhead - every DB has some indicator that a record is marked as deleted, 
although it is actually still there until cleared by some means.

RPG embedded SQL uses some mechanism to translate this bit-array into an array 
of 2-byte integers. Same in C. Again, RPG is very helpful when handling fields 
directly, a little clumsier when going through SQL.

-------------- Original message -------------- 

> >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