|Subject||RE: [IBO] Transaction Advice Needed|
>Yes, exactly. :-) I have one transaction that handles, for example, all the
>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
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.