Hi Helen

> Yup, you've certainly pinpointed the cause of the poor performance.
>
> Definitely don't perform this operation on a table object. If you insist
> on doing this as a client-side operation, you want the smallest possible
> subset in the buffer -- replace the detail set with a parameterised query
> ("where TheDetailFK = :TheMasterPK).

a) Are you suggesting a live query? I have to keep the table component (for
now) so this would require another query to run and a refresh on the table
afterwoods. I take it I would still have to step through the results of the
query and apply my tax logic?

> If you really-really-really don't want to do this server-side (the proper
> place for it, in a trigger) then use a prepared, parameterised update
> statement that you fire off from a TIB_DSQL in the same transaction

context

> as your datasets. Apply your function to the relevant parameter[s] in the
> BeforeExecute event of the IB_DSQL after you've applied and posted the new
> rate to the master. IOW, don't touch the detail dataset at all.

b) Sorry if I'm being thick here. Are you suggesting I move through the
orignal table and insted of editing and posting, send my changes through as
update SQLs?

>
> Once the IB_SQL has finished, post any outstanding changes from the detail
> dataset and refresh it. Done, quick as a wink.
>
> The biggest break-through you will make when moving from desktop to
> client/server is when you realise that everything you do on the client is
> operating on a local snapshot of what came over from server at the
> beginning of the transaction (and erk!! a table component is one horribly
> panoramic snapshot!!).
>

Yes I would dearly love to get rid of the table components but I am already
3 months behind schedule. At this point I need to get something out!

> When you've got to do something iteratively like this, a direct searched
> operation on the underlying server-side set bypasses all that noise and
> risk and removes this legacy bottleneck that you inherited from the

desktop

> db app. It has a lot of benefits, not the least of which is that, if the
> update can't happen for some reason, e.g. an update conflict or a CHECK
> constraint, the application will know about it *before* it commits itself
> to chewing up all those processing cycles. It all translates to a much
> more responsive application for your users.

Are you referring to your suggestion a) here?

Thanks for all your help Helen. I look forward to seeing what sort of
performance boost I can get :)

Rob Martin
Software Engineer

phone 03 377 0495
fax 03 377 0496
web www.chreos.com
Wild Software Ltd

[Non-text portions of this message have been removed]