Transaction does not start nor do a commit/rollbac

[Lange_Helge]

@Wagner R. Landgraf

Ok, I understand.
First point is: that approach is not cross-database. As far as I know, Interbase/FB is the only database that supports such multi transaction paradigm (multiple parallel transactions for a single connection). If you intend to use/port your code to a different database, you will have to find a different approach anyway.

I think, MS-SQL server behaves the same way, but also I haven'¡t worked with it for years, I might remember wrong.

@Wagner R. Landgraf

Second, Aurelius provides mechanisms to minimize that. You are working with objects, and thus it's much easier to "cache" things and save later. For example, you can create a TInvoice object, then several TInvoiceItem objects and add them to TInvoice.Items property, and only later save the whole TInvoice object. It's not always possible to cache lots of operations, but in this specific case, you can do that.

We'd have to see, how that works, if we use a TAureliusDataset with a grid, that the caching would work.

@Wagner R. Landgraf

Having said all that, we might consider creating a new interface IDBConnection2 that adds a new method BeginNewTransaction (instead of BeginTransaction) which will effectively create a new transaction object. That will only work for Interbase/FB and only for the selected component database access (in this case, UniDac).

That sounds like we're getting somewhere :)

Aurelius has some adapters, that work with interbase/FB, like FireDac, IBO, FibPlus, IBX and probably UIB (with that one I haven't worked with).

But in that case you will have to let us tell the ObjectManager which transaction we want to use, so that all statements (queries) used by that ObjectManager are using this context, right ?

Thanks for that consideration, this would help a lot using Aurelius in something bigger  :)

[wlandgraf (Wagner Landgraf)]

All databases can have multiple transactions, as long as each transaction is in a different connection. All that could be solved, by the way, and code would be cross-platform, if you simply use a different connection for each different transaction you would like to use. 

That's how it's built, each object manager can use a different connection. Why don't you consider it? Aurelius is already big! :-)

[Lange_Helge]

Using a connection for every form is a bit of an overhead, no? 

I think it would be easier to create a new object manager (TTransactionalObjectManager) that inherits everything from TObjectManager but introduces a transaction and has the methods overwritten, that create statements and does commits etc.

[wlandgraf (Wagner Landgraf)]

@Helge Lange

Using a connection for every form is a bit of an overhead, no?

Why?

[Lange_Helge]

Opening 1 connection for every form :O

I think, 500 years ago people got burned on the stake for heresy :P

A connection object takes MUCH more memory to have and I loads the server with more connections that it has to. Imagine a company with some 100 workstation and in every workstation I open 20 connections for standard objects that I need to run in the background + another for every form :O Peopke will burn me on the stake here, it's a very catholic country in south america where I live :D

[wlandgraf (Wagner Landgraf)]

Keeping transactions open for so long is also not a good idea:

https://stackoverflow.com/questions/1968437/are-long-living-transactions-acceptable