At 12:13 AM 10-05-02 +0000, jon freedman wrote:

>should i, if i am responsible for developing both the server database
>and the user interface, used stored procedures to select data for
>viewing, update data, and otherwise control all the transmission of
>data from the server to the client, and call them thru stored
>procedure objects instead of query objects?

In short, no. You lose most of the benefits of the IBO "live dataset"
model that way. A dataset that is output from a dynamic query knows how to
insert into, delete rows from, and update itself. It knows how to search
and filter its underlying tables and so on. If there are no underlying
tables, it capabilities are limited.

The other big catch is that, as soon as one row in a SSP output set becomes
invalidated by changes in the source tables, it invalidates the whole set.

That's not saying "don't use stored procedures". They have a highly
important part to play in making read-only datasets (from joins,
sub-selects) capable of being "live" (through the xxxxSQL properties),
since they are the perfect solution to DML that has to hit multiple
tables. Selectable SPs provide a very efficient mechanism for providing
"semi-static" data for complicated selection lists and for ledger-style
views. So include them in your amoury: just don't think of them as a
substitute for dynamic SQL.

Just as an added tip: don't use stored procedure objects for DML. A DSQL
object is much more efficient.


regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at
www.ibobjects.com