| Subject | Re: [ib-support] SELECT in stored proc returns wrong value |
|---|---|
| Author | Lukas Zeller |
| Post date | 2001-06-18T18:38:58Z |
Helen,
At 16:21 +1000 18.6.2001, you, Helen Borrie wrote:
But "sloppy" is a bit unfair, as Interbase docs (besides being very
readable and informative in general) is VERY weak in some of these
points. Especially the role of NULL in general is not explained well
anywhere. When I was an IB newbie (the episode above happened then, too),
for example I had quite some problems with NULLs in comparisons. Only
one sentence said something about a third state UNKNOWN, but without
any explanation how to handle it. I had to figure this and
many other things out myself (and fortunately, with help of people
like you on these lists :-) - and still I have no full understanding
of NULL in comparisons.
Still, I think a statement that can return NOTHING or SOMETHING
without a precise means to find out which one has actually happened
is not "just ok". The SELECT COUNT() test is only really consistent
with the result of a subsequent fetching SELECT
if both happen in a highly isolated transaction context. This
again is not desirable nor possible in general for executing
super-simple stored procs like this one.
As "correct" the behaviour might be from a strictly technical
point of view, I criticize that it is
a) not obvious for the IB beginner so it should be documented
b) incomplete functionality as the "check if value was overwritten"
test that seems to be the only solution is a rather ugly workaround.
Regards,
--
Lukas Zeller (luz@...)
-
Synthesis AG, Sustainable Software Concepts
info@..., http://www.synthesis.ch
At 16:21 +1000 18.6.2001, you, Helen Borrie wrote:
>At 08:33 PM 17-06-01 +0200, Lukas Zeller wrote:...as I said a few lines further down my posting...
>
> >I'd guess, Interbase. [...]
>
>A bad guess, I think. An empty result set is an empty result set.
>It doesn't contain nulls because it doesn't contain anything.
>If anyone thinks IB does ever return an empty set as a row of nulls,This might be correct when you know as much abour Interbase as you do.
>then he is mistaken. If IBConsole or some other tool does this,
>then it's the tool that is inconsistent, not IB.
>
>Sorry to be blunt, but to me this stored proc was just an example of
>sloppy programming.
But "sloppy" is a bit unfair, as Interbase docs (besides being very
readable and informative in general) is VERY weak in some of these
points. Especially the role of NULL in general is not explained well
anywhere. When I was an IB newbie (the episode above happened then, too),
for example I had quite some problems with NULLs in comparisons. Only
one sentence said something about a third state UNKNOWN, but without
any explanation how to handle it. I had to figure this and
many other things out myself (and fortunately, with help of people
like you on these lists :-) - and still I have no full understanding
of NULL in comparisons.
Still, I think a statement that can return NOTHING or SOMETHING
without a precise means to find out which one has actually happened
is not "just ok". The SELECT COUNT() test is only really consistent
with the result of a subsequent fetching SELECT
if both happen in a highly isolated transaction context. This
again is not desirable nor possible in general for executing
super-simple stored procs like this one.
As "correct" the behaviour might be from a strictly technical
point of view, I criticize that it is
a) not obvious for the IB beginner so it should be documented
b) incomplete functionality as the "check if value was overwritten"
test that seems to be the only solution is a rather ugly workaround.
Regards,
--
Lukas Zeller (luz@...)
-
Synthesis AG, Sustainable Software Concepts
info@..., http://www.synthesis.ch