>
> Hi Eyal,
> ...
> I think you just miss the potential of transactions. Take a few time
> and learn about it. See the examples that IBO provides you.
>
> Artur

Artur,

Thanks for the detailed reply.

I do understand the usefulness and power of transactions. However I'm
trying to minimize the ping-pong between the client and the DB. Also I
hope to minimize thrashing the DB with records that are
writte/updated/deleted many times for just a single transaction.

If I use "live" datasets, then each row is updated when the user
exists the row in the GUI. The user may add/modify/delete rows many
times before finally completing data entry. If I just let everything
pass through to the DB, then it will cause a lot of traffic and file
I/O on the server (assuming forced-writes).

Then, once the user is done, I have to do my validation and updates on
the data, so there's another round of re-writing the rows.

I understand that all this activity is hidden from any other
users/transactions, but it's still a lot of redundant I/O.

Another problem with "let the transaction be your playground" is that
the user may just take a coffee break or even go home with the data
entry form open. This may leave a transaction open for a very long
time which is A Bad Thing. So I'll have to implement an inactivity
timer that closes the form and frees the transaction.

I was thinking more along the lines of caching all user input in
memory, then doing "my stuff" to validate and fix the data, then start
a transaction, post everything and end the transaction.

Anyway your reply, along with Helen's, did clarify a lot of things for
me. Once I digest all the information I'll probably have a good idea
how to do it right. Or I'll be back here with more questions...

Thanks,

Eyal.