Subject | Re: Can SLCODE 100 be trapped in an SP? |
---|---|
Author | Alexander V.Nevsky |
Post date | 2002-10-18T08:54:38Z |
--- In ib-support@y..., Bill Katelis <bill@s...> wrote:
faster if you are interested just in existance at least one record.
Notice "singular" too if you are interested in existance only one
record.
operation on cursor, i.e. internally it is loop, you an me can be
shure there will be only one record affected, but server can't until
he don't perform it. So, he report "I searched records, performed what
you asked and did'nt find next record using your condition to update".
BTW, there is feature request in FB traker to provide ROWSAFFECTED
system global variable for SP/triggers which can be checked after
execution of statement.
Best regards, Alexander V.Nevsky.
> Alexander,that
> Yes - I can work around it using a 'select count(*)' or checking
> the host variable is not null.Bill, I recommend "exists" instead "count", it is significantly
faster if you are interested just in existance at least one record.
Notice "singular" too if you are interested in existance only one
record.
> Now I am intrigued - why would it be set to 100 given that that isthe
> 'not found' condition ?I understand it that way: any SQL statement is in general case
operation on cursor, i.e. internally it is loop, you an me can be
shure there will be only one record affected, but server can't until
he don't perform it. So, he report "I searched records, performed what
you asked and did'nt find next record using your condition to update".
BTW, there is feature request in FB traker to provide ROWSAFFECTED
system global variable for SP/triggers which can be checked after
execution of statement.
Best regards, Alexander V.Nevsky.