Helen Borrie wrote:

>>I have a question about using a single (global, so to speak) TIB_Cursor
>>component (perhaps on a DataModule) for all SELECT statements for an
>>entire application.
>>
>>I can think of three options:
>>1. Using the same curFactotum for every select:
>>2. Create 500 'static' TIB_Cursor components with 'static'
>>parameterised SQL:
>>
>>3. Set up, and select from, a Stored Procedure
>>-------------------------------------------
>>Also: Is the result of calling "unprepare" (releasing resources on the
>>server?? Nothing else?) carried out automatically by calling
>>"curFactotum.SQL.Clear" ?
>>
>>
>
>Well, theoretically, all are possible. Whether they make sense or not is
>another thing entirely.
>
>Your model of pulling a set over to the client, doing something
>user-invisible to it and then sending update statements back one by one
>isn't a sensible client/server strategy. If you have 450 places where the
>application is interested in data, and 440 of those "places" are update,
>insert or delete operations, then you don't want datasets for them, you
>want executable statements. Then, it's valid to have a single factotum
>ib_cursor or, better, ib_dsql, to carry out those tasks directly. For the
>other 10 you probably need scrollable datasets (ib_queries),
>well-controlled with parameters and transaction management.
>
>Helen
>
>
>
>

Helen:

Thank you for your reply. I might have been more clear: The 450 SELECT
statements that I am referring to are used to get data [only] to display
to the user. On the one hand, a user is going to frequently look up an
existing customer's name and address info (basic 'record'), so I have a
"static", parameterised TIB_Cursor component dedicated to that. (select
a,b,d,c,..... from customers where customer_id =?)

But every once in a while the user will click the [fictitious] button
that says "Display the invoice number of this customer's last purchase."
For those individually uncommon -- but very numerous in the aggregate
-- SELECTs, I use the factotum TIB_Cursor (called curMisc), thus:
curMisc.SQL.Clear
curMisc.SQL.Add('SELECT INVOICENUMBER FROM ......... WHERE
CUSTOMER_ID=1234');
curMisc.Open;
if not curMisc.eof then Edit1.text (or Label1.caption) :=
Fields[0].AsString;

There are scores -- hundreds -- of these "miscellaneous" queries
throughout the [large] application. Knowing that a stored procedure can
be poised, so to speak, on the server, ready to fire back that invoice
number upon receipt of a mere integer parameter (customer_id) over the
wire, I have long wondered whether it was a bad idea (re: server and
network performance) to pass those SELECT statements over the network as
they are needed, and have the server prepare and execute them, instead
of having either a dedicated TIB_Cursor for each one, or even a stored
procedure for each one.

What I take away from your response is: "Then, it's valid to have a
single factotum ib_cursor or, better, ib_dsql, to carry out those tasks
directly" -- which is what I am doing: a single ib_cursor component for
selecting data to display, a single ib_dsql component for updates, in
both cases clearing and assigning the new SQL property needed for the
occasion.

Thank you again, Helen. You are terrific. So's your book. I bought two.

p.s. I do use a single factotum TIB_DSQL for many of the hundreds of
updates in the application.
p.p.s. I use a half-dozen TIB_Query components(with TIB_Grid) for
major lookups (Customers, Suppliers....)
ppps: My brother spends about half his year in Coffs Harbour.


Dennis McFall

>
>
>