Subject | Re: [firebird-support] NULL confusion, again |
---|---|
Author | Helen Borrie |
Post date | 2006-04-21T06:11:09Z |
At 11:25 AM 20/04/2006, you wrote:
to what is returned to a variable if there are no matching rows. The
poster (don't know if was you) thought that an "empty set" was "a row
of nulls" so that null would be passed into the variables. As I
pointed out, there is no such thing.
Delphi programmers (particularly) develop this misconception and it's
pretty hard to shake some of them out of it.
shake off your belief that "a state of non-existence must be
something we can measure and cut". To be fair to Delphi programmers
everywhere, many of us cut our Delphi DB programming milk teeth on
Paradox which doesn't support null. The BDE (which is the Paradox
engine) returns a result set consisting of a single row of "zero-ed"
values (0 for numerical values, empty string for strings). That
works for Paradox, but it's an absurdity that we don't have to
contend with in Firebird.
./heLen
>Hello,No, you didn't understand correctly. The other message was in regard
>
>The other day i posted a rather lengthy message about a (self-induced)
>bug because i did not initialize a variable properly. The conclusion i
>get from the response to that post is that these are 'normal' constructs
>in firebird's stored procedure language :
>
>...
> total = 0;
> select sum(...) form other_table into :total;
>...
>
>Again, if i understood Ms Helen Borrie's message correctly, if the
>select returns NULL, the variable total will not be affected, so it will
>be still be zero.
to what is returned to a variable if there are no matching rows. The
poster (don't know if was you) thought that an "empty set" was "a row
of nulls" so that null would be passed into the variables. As I
pointed out, there is no such thing.
Delphi programmers (particularly) develop this misconception and it's
pretty hard to shake some of them out of it.
>Today (at 5 AM, duh), i encountered another case with these lines :Yes, it's a perfect example of how you need to think, in order you
>...
> total = 0;
> select sum(detail.amount)
> from master
> join detail on (master_id = detail_id
> where (master.trans_date < :end_date) and
> (detail.item_id = :item_id)
> into :total;
>...
>
>Since the tables are empty, the result of the variable TOTAL is always
>NULL inside this stored procedure (Firebird 1.5.3, Win32). This kinda
>contradicts my conclusion above (about how a SELECT INTO that returns a
>NULL will not affect the variable value).
shake off your belief that "a state of non-existence must be
something we can measure and cut". To be fair to Delphi programmers
everywhere, many of us cut our Delphi DB programming milk teeth on
Paradox which doesn't support null. The BDE (which is the Paradox
engine) returns a result set consisting of a single row of "zero-ed"
values (0 for numerical values, empty string for strings). That
works for Paradox, but it's an absurdity that we don't have to
contend with in Firebird.
./heLen