At 08:15 AM 27/04/2006, you wrote:

>Let's say I am using a single TIB_Cursor component on the main form
>to handle 100 different SELECT statements, by CLEARing and ADDing to
>the SQL property as needed. For example:
>
>Button1Click:
>with curData do try
> SQL.Clear;
> SQL.Add('SELECT THIS, THAT, OTHER FROM SOMETABLE WHERE ITEMID=?');
> Prepare;
> Params[0].AsInteger := iSomeInteger;
> First;
> if not eof then begin
> // do something
> end;
> finally
> Close;
> end;
>
>
>Button2Click:
>with curData do try
> SQL.Clear;
> SQL.Add('SELECT ALPHA, BETA, GAMMA FROM TABLE2 WHERE FOO_ID=?');
> Prepare;
> Params[0].AsInteger := iOtherInteger;
> First;
> if not eof then begin
> // do something
> end;
> finally
> Close;
> end;
>
>Does it make any difference, as far as memory or other resources are
>concered -- on either the client workstation or on the Firebird
>server -- whether there is an "Unprepare" in the try...
>finally block?

No, but it's not needed. Calling SQL.Clear will cause a call to Unprepare.

>Does the query in some way ever get unprepared on the
>server without my calling "unprepare".

Yes. Anything you do that changes the structure of the output set
(in the case of a SELECT statement) or of the input stream (in the
case of an INSERT statement) will cause the SQL to be
invalidated. Merely applying new values to an existing input or
output specification doesn't invalidate the statement.

Of course, those who follow the practice of totally replacing the SQL
string every time they submit a request, even if the spec is
unchanged, cause the invalidation to occur and the costly
repreparation each time. It's a careless practice usually inherited
from converted BDE apps and it's a performance-killer.

It's always a good practice (IMO) to test for Prepared before
submitting a statement of any kind (as recommended in my previous
post). It eats nothing and it ensures that the bases are always covered.

>I assume (?) that "Prepare"
>takes up some RAM on the server as the data structures are created to
>receive the param values and to return the results. When/how is that
>memory released if I don't explicitly call Unprepare?

Indeed, Prepare uses a lot of resources at the server and CPU cycles
at the client so the better you manage user sessions, the leaner and
meaner your system will be. Unless you DO call Unprepare, the
prepared resources are not released until the statement object is
destroyed. If you have clients that tend to wander off, e.g. browser
clients, it's not at all a bad idea to create and destroy data access
objects dynamically and to monitor client sessions with the timer
with a view to pouncing on neglected resources.

Helen