Subject | RE: [IBO] Prepared Statements and Memory Usage |
---|---|
Author | Helen Borrie |
Post date | 2005-04-13T03:28:41Z |
At 10:38 AM 13/04/2005 +1000, you wrote:
required. ClearBuffers isn't contextually appropriate to an unbuffered
statement (which an executed DML statement is).
*should* call this itself, but it would really be worth testing, if only to
verify that it does.
source of the memory leak. Yesterday you said:
I've been looking further into my code for this and tried a few things.
Commenting out all of the code *after* the prepare stops the memory jumping
when prepare is called (I can't see why though). Without the code commented,
when i step over the Prepare() call the memory jumps up by ~20Mb. Looking
further I called Unprepare() after the Prepare() call and the memory was not
freed (this *has* to be something in my app).
What *is* this code following the Prepare?
Also, do you have any handler code in OnPrepareSQL?
Do you have any blobs as parameters? If so, are you binding them to any
run-time objects (stream, TStrings) that you are forgetting to destroy
afterwards? Or are you maybe reading the entire source data for a row into
some kind of run-time structure that keeps getting created but is never
destroyed?
one TIB_Row object: the Params[] array. Stay away from methods pertaining
to buffers, because there are no buffers other than Params, which
Params.Clear takes care of specifically. It literally removes all of the
individual IB_Column objects in Params, i.e. makes ParamCount 0.
Helen
>Hi,IBO will make the contextually appropriate call to ClearBuffers if it's
>
>In reading the Help for IBO, I found that calling Unprepare does not clear
>the parameters in the buffer, and you have to call:
>
>query->Params->ClearBuffers(rsNone);
required. ClearBuffers isn't contextually appropriate to an unbuffered
statement (which an executed DML statement is).
>Could it be possible that not calling this is whats causing the memory usageTest it with an explicit Params.Clear after the Unprepare call. Unprepare
>to increase?
*should* call this itself, but it would really be worth testing, if only to
verify that it does.
>I have found a work-around for it (not the greatest though), by deleting andI'm sure this is the wrong way to go about this. You need to find the
>re-creating the TIB_DSQL each iteration the memory stays level (or with very
>minor 'twitches'). Not a great solution, I know, but it works.
source of the memory leak. Yesterday you said:
I've been looking further into my code for this and tried a few things.
Commenting out all of the code *after* the prepare stops the memory jumping
when prepare is called (I can't see why though). Without the code commented,
when i step over the Prepare() call the memory jumps up by ~20Mb. Looking
further I called Unprepare() after the Prepare() call and the memory was not
freed (this *has* to be something in my app).
What *is* this code following the Prepare?
Also, do you have any handler code in OnPrepareSQL?
Do you have any blobs as parameters? If so, are you binding them to any
run-time objects (stream, TStrings) that you are forgetting to destroy
afterwards? Or are you maybe reading the entire source data for a row into
some kind of run-time structure that keeps getting created but is never
destroyed?
>I havent been able to try the ClearBuffers because I keep getting anIt's a member of the enumerated set TIB_Rowstate. In a DSQL, you have only
>Ambiguity compile time error (with the rsNone), is anyone able to help out
>with what namespace this is in?
one TIB_Row object: the Params[] array. Stay away from methods pertaining
to buffers, because there are no buffers other than Params, which
Params.Clear takes care of specifically. It literally removes all of the
individual IB_Column objects in Params, i.e. makes ParamCount 0.
Helen