At 09:43 AM 8/09/2005 +0200, you wrote:

>Helen,
>i switched to IB_Cursor and use a "close" after each "execute" of a
>stored procedure.

"Close" is meaningless with an Execute operation.

>But the overflow is happening at the same place within
>IB_components after a large number of calls to the storedprocedure.
>During a quick scan through ib_components.pas I can't find any
>statements decreasing the value of FcursorGen (only setting it back
>to zero in case of an exception).
>is there still something wrong the way I'm calling the stored
>procedure?

Yes, as I explained yesterday. Either you will execute a procedure
(usually parameterised) that *does* something in the database and then
returns; or you will SELECT from one that returns a result set. You might
call either of such procedures once or a few times in a transaction; but
certainly you wouldn't plan to have it executing 30,000 + times in a single
transaction. On the client side, you would break the task up into a
logical task that either tackles a big, repetitive job in
transaction-friendly batches; or, in the more common case, the execution
(once) of a SP would be a once-per-transaction event.

As I said, I don't know the purpose of the FCursorGen variable but my best
guess is that it's to put an absolute limit on the number of concurrent
executions. Given that SPs are designed to operate on data, on the server,
and specifically NOT to replace functions (either on the server or in
client code) it would seem a proper and reasonable thing to build this
safeguard in. That way, your code can intercept the exception and handle
it before it becomes too big a problem on the server. (Although I would
want it to throw the exception long before it hit the limit of a signed word!)

However, as I suggested before, Jason is the one who can explain to you
exactly what his intention is there.

Helen