Designing transaction in the code equals designing problems

[high_flyer]

One Sentence - inability to come up with something common for all classes which must be controlled if necessary by TransactionHandler

Well, even though my answer is very general, what I would suggest is to look at all your objects that have transactions, and either find common logic steps that all go through, or force all of them to comply to predefined logic steps.
In other words - define an interface that all these object will implement.
Then, in your handler, call these steps based on the common logic that fits your interface.

I fully agree with you, that this should be encapsulated in its own module, and should not be mixed with GUI code.

Since I am at work, I don't have the time to look deeper in your code, or suggest some code for you.
But sometimes a push in the right direction is all what people need.

From what I can see in the header you posted, it looks a step in the right direction, but is a bit different from what I suggested just now.
Your manager doesn't need to implement the interface that your query object do, it should implement the logic of calling the right actions at the right time/sequence.

In other words: you query object should the know the "how".
Your manager should know the "when".

I am stuck with the one class I have which is to control other classes when transaction mode is on...

What exactly are you tuck on? which part or detail?

[kornicameister]

I see Your point
I will try to implement it after I solve the problem I posted in the different thread about sharing the data.

[marcvanriet]

...transaction-controlling code in the gui-code is something I don't want to have...

Didn't suggest this either. 'functional level' or 'application level' doesn't (always) mean GUI

Your handler actually needs to perform "object to place in the table A", because only after performing the it you will know "lastInsertedId". But the handler itself doesn't know anything about "lastInsertedId". It may not even be in the SQL statement if it is auto-generated. And it sure doesn't know that any queries will be executed after that or not, and if they use the value of lastInsertedID.

The only thing I can come up with is to pass the queries to your query handler along with some metadata. So something like addQuery(QueryHandler *query, QString dependencies );. For the first query you should say "begin lastInsertedId". The handler should start a transaction for any query for which you say there are dependencies. The queries are executed immediately. For the following queries you should say "uses lastInsertedId". And then you must say something like 'commit( "end lastInsertedId" )' to let the handler know that no further queries will depend on lastInsertedId. The handler should only really commit the queries if there is an 'end' for each 'begin'.

Regards,
Marc

[kornicameister]

That sounds interesting... now I know how step-by-step process can look like more than five minutes, when I was circling around a solution with passing an enum which would determine the decision (insert etc)... thanks for that tip
I will write all steps on the paper... maybe I will see something common like high_flyer suggested

[kornicameister]

I was thinking...
QSqlQuery has this feature lastId... is it possible to access it everywhere at anytime ?