Subject | Re: [IBDI] RowsAffected in SP/Trigger |
---|---|
Author | Ann W. Harrison |
Post date | 2001-06-07T14:59:58Z |
At 11:49 AM 6/7/2001 +0400, Alexander Nevsky wrote:
and "system variables are nasty beasts."
It's not necessary because:
You can, of course, run updates and deletes through a for select loop
- there is no loss of efficiency and you have a place to put a counter
and can return that value from a stored procedure. A trigger could,
one supposes, write the value to a statistics table.
System variables are nasty beasts because:
They don't work well in modular programs and modular is the only way
to go (my opinion, perhaps, but very correct). What value does the
SQLUPDATE_COUNT have after you've invoked a procedure that does three
updates then calls another procedure that does five more and calls
another that does ... and so on?
Regards,
Ann
www.ibphoenix.com
We have answers.
> Hi, All. I've teached at last this Yahoo to show my name! :)I suppose that you wouldn't agree with arguments like "it's not needed"
>It's often asked in NGs how to know amount of rows affected by Update
>from SP/trigger. It's certainly known for engine, API connectivity
>componets have this property, but SP/trigger syntax does not support it.
>Why not to have system variable for it in Firebird, like SQLCODE?
and "system variables are nasty beasts."
It's not necessary because:
You can, of course, run updates and deletes through a for select loop
- there is no loss of efficiency and you have a place to put a counter
and can return that value from a stored procedure. A trigger could,
one supposes, write the value to a statistics table.
System variables are nasty beasts because:
They don't work well in modular programs and modular is the only way
to go (my opinion, perhaps, but very correct). What value does the
SQLUPDATE_COUNT have after you've invoked a procedure that does three
updates then calls another procedure that does five more and calls
another that does ... and so on?
Regards,
Ann
www.ibphoenix.com
We have answers.