>
>In a word, Tim, if I understand your description, it's **bizarre**. You
>seem to be saying you split a task up so that each different type of
>operation on a record (select, update, insert, delete) is in its own
>transaction...
>
>Helen
>

Yes, exactly. :-) I have one transaction that handles, for example, all the
updates, etc, etc, etc.

It may well be bizarre.

Nevertheless, I have found it considerably easier to use than havign one
transaction do everything.

Again, I think this may well be my bad old BDE habits - but what it means
is that I keep everything separate. I found it very difficult moving from
database.starttransaction to stand - alone transaction objects. I also
found that they kept of clashing with each other - that I would have
unpredictable (well, for me, anyway) behaviour in terms of displays.

I suppose the question is - is there any overhead in doing it this way? Is
there any technical reason why I shouldn't?]

Now that I think about it - I think the problem that I had was that the
documentation that I read at the time, or comments that I read, said that a
datamodule only needed one Transaction object ...

I found this impossible to do.

I was faced with the "standard" programming problem - a screen with a data
entry part on the top, together with a few data aware objects reflecting
data from other datasets that the user should choose from, and a DB Grid
beneath, showing records in the data set that was inserted into.

How could I do this with transaction obejcts? :-)

The only way i could think of was the way I still use ... :-)

I would be more than happy to hear of any suggestions of ways to do it better.

Regards

Tim