Re: A nongeneric bounded string array type (in database code)

["Robert I. Eachus" <rieachus@comcast.net>]

Warren W. Gay VE3WWG wrote:

> Using a fetch loop that processes one row at a time is so
> much easier (at least when possible). This eliminates the resource
> issue. The CLIENT LIBRARY should already be handling the EFFICIENCY
> aspects of fetching, in bunches of rows, thus freeing your code
> from such implementation details.
> 
> If you insist on arrays at a time processing, then you
> are usually focusing on efficiency, which is very implementation
> minded design. This is what many Ada people try to get
> away from (and certainly my focus).

No, there are queries where the normal case is one matching record, and 
discriminating between two (or more) records is an extra step.  When I 
go to the drug store, they check my date of birth because they also have 
records for my son.  (The same thing happens at the HMO, but they 
usually figure it out without asking me if I was born in 1946 or 1982. ;-)

> As a side note, your Ada_Strings_Bounded_Array package makes a
> common mistake: it does not allow for the processing of NULL
> values. This is one fault I see so frequently in embedded SQL
> code, because the programmer never took the trouble to code
> for that possibility. This leads to all sorts of hideous
> problems when NULLs are encountered in processing. There is
> no doubt that Ada_Strings_Bounded_Array could be augmented
> to handle this, but does illustrate how this RDBMS feature
> gets overlooked. Microsoft is another one that is guilty of
> this in their database controls (try handling a null date
> type in the date picker, for example ;-)

You are confused.  The Ada_Strings_Bounded_Array package allows for null 
strings in any row, and an array with no rows. (Or both. ;-)  Was there 
some other type of NULL value I should allow for?

 > If you take arrays to the further level of columns x rows, then
> you have a 2-dimensional array to mess with -- which in my view
> is very dangerous from a code readability/code-write-reliability
> point of view. Don't get me wrong, arrays have their place.

No, as far as I am concerned, it handles perfectly the case where you 
expect a "few" matches, for some version of few.  As you say, for cases 
where you expect many matches, an iteration scheme is better, and if 
zero or one matches, a string is fine.

Let me use the registry for Ada packages that I have been proposing as 
an example.  If I did a search for packages named ODBC, that would be a 
good case for the "few" type query.  A query for all database packages 
would best be handled by returning an iterator of some sort.  A 
programmer can decide on the best query for his particular purpose.

-- 
                                         Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig