At 11:33 PM 9/05/2003 -0700, you wrote:

>If my app has several stored procedures that I plan to call in my code, how
>would I handle creating/handling TIB_StoredProc objects? The options that
>I see are as follows:
>
>1) Drop a TIB_StoredProc on the form for each stored procedure in my
>database. Access the appropriate object depending on which SP I want to call.
>
>2) Just have one generic TIB_StoredProc on my form. When I want to call an
>SP, just change the StoredProcName property to refernce the SP I want to
>call. Use AutoDefineParams to keep the paramater list correct.
>
>3) Create TIB_StoredProc objects dynamically at run time in my code, set
>the necessary properties, and execute.
>
>Are all 3 viable options? Is any of them better or more efficient?

IMHO, none of them is efficient. I don't touch TIB_StoredProc, ever.

For executable SP's I use TIB_DSQL. For selectables, I use TIB_Query when
I want a scrolling dataset, TIB_Cursor when I don't.

My rule for create-time vs run-time creation is likely frequency of
use. If the same SP is going to be called again and again with different
parameters, at random, it makes sense to create it at create-time, prepare
it once the first time it's called and then select or execute it as
required. I don't want to waste resources on continually creating,
preparing and destroying instances of the same object if the only variable
factor is the input parameters.

At the same time, I don't want to waste resources on a data object that
might not be used. If it's something that might be done once or twice in a
session but commonly wouldn't be done at all, then run-time creation might
make more sense. As a general rule for dynamic creation of data objects,
don't do it unless the SQL is completely ad hoc. Unnecessary Prepares are
a terrible drag on performance.

Executables, along with any "one-off" selectables that are used just to
fetch or refresh data for a lookup list, I run in an independent "hit and
run" transaction with full commit or rollback, no retaining.

Helen