|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.