Subject | RE: [ib-support] SELECT in stored proc returns wrong value |
---|---|
Author | Christian Gütter |
Post date | 2001-06-18T20:24:28Z |
Hi Helen, Ann et al,
thanks for your answers.
Your explanations made me change my opinion that this could be
a bug.
Ann> Sorry, no, it's not a bug. As Helen said, a select that returns
Ann> nothing doesn't change the variables used in the INTO clause. If
Ann> they were null to start, they'll still be null. If not, not.
I still see two different behaviours in nearly the same case,
but you say IB consistently returns nothing for these kinds
of selects.
I trust in your expertise and so I believe you - this leads
to the opinion that the inconsistent results must be a result
of a buggy behaviour of the client application I used to execute
the selects.
Helen> Sorry to be blunt, but to me this stored proc was just an example
of sloppy programming.
I don't see the point in this remark.
I didn't just present the code of my SP and asked: what is wrong?
I presented one example of a select statement which returned NULLs as
result.
I have seen this very many times and so I concluded this was the normal
behaviour:
the result is null, not nothing.
I presented the same select statement in a stored procedure which
returned nothing and left
the variables of the INTO clause unchanged.
I considered this to be buggy behaviour because the first example made
me think that a select
statement with no result returns NULLs.
_Of course_ I saw that it would be a workaround to initialize the
variables in every loop, but
I decided to asked this question anyway because:
1) initializing variables takes a lot of time because the loop is run
through many times
2) Why should you initialize variables if you think the correct
behaviour is that they are
overwritten anyway, regardless of the result of the SELECT?
Please don't get me wrong: I don't feel insulted by your remark, but I
think you misunderstood
the problem. I didn't ask why the stored proc does not work (I even knew
that initializing the
variables would cure the problem), but I was asking why the select in
the stored proc behaves
differently from the first select statement I presented.
Maybe this misunderstanding occured because my English is not so good.
Anyway,
thanks for your help!
Christian
thanks for your answers.
Your explanations made me change my opinion that this could be
a bug.
Ann> Sorry, no, it's not a bug. As Helen said, a select that returns
Ann> nothing doesn't change the variables used in the INTO clause. If
Ann> they were null to start, they'll still be null. If not, not.
I still see two different behaviours in nearly the same case,
but you say IB consistently returns nothing for these kinds
of selects.
I trust in your expertise and so I believe you - this leads
to the opinion that the inconsistent results must be a result
of a buggy behaviour of the client application I used to execute
the selects.
Helen> Sorry to be blunt, but to me this stored proc was just an example
of sloppy programming.
I don't see the point in this remark.
I didn't just present the code of my SP and asked: what is wrong?
I presented one example of a select statement which returned NULLs as
result.
I have seen this very many times and so I concluded this was the normal
behaviour:
the result is null, not nothing.
I presented the same select statement in a stored procedure which
returned nothing and left
the variables of the INTO clause unchanged.
I considered this to be buggy behaviour because the first example made
me think that a select
statement with no result returns NULLs.
_Of course_ I saw that it would be a workaround to initialize the
variables in every loop, but
I decided to asked this question anyway because:
1) initializing variables takes a lot of time because the loop is run
through many times
2) Why should you initialize variables if you think the correct
behaviour is that they are
overwritten anyway, regardless of the result of the SELECT?
Please don't get me wrong: I don't feel insulted by your remark, but I
think you misunderstood
the problem. I didn't ask why the stored proc does not work (I even knew
that initializing the
variables would cure the problem), but I was asking why the select in
the stored proc behaves
differently from the first select statement I presented.
Maybe this misunderstanding occured because my English is not so good.
Anyway,
thanks for your help!
Christian