Quote:
Originally Posted by
pippo42
1. The user does not know, before the update, if his changes will be accepted. It would be better to react at the beginning of the edition.
That would be premature and inefficient. If someone starts editing an item and then leaves the computer before leaving edit mode, the record would be locked and nothing else could access it.
Quote:
2. I would have preferred it if the program did not access all the time the database.
It's just a matter of submission strategy you set. You can tell the model to submit the data just once.
Quote:
3. I have a strange bug when I am not using the "on manual submit" strategy. When I edit a cell, another in the table is randomly modified. I have posted a message here but found no solution
Provide more info, please.
Quote:
4. It freezes. It would be better to have an error message like when you have done a SELECT FOR UPDATE NOWAIT
What freezes? In what conditions?
Quote:
And, what would be the natural way to implement the locks in Qt? I assume there something for that. I do not ask for a ready made solution. But if someone could point me to a piece of documentation, give me a class name...
What is the exact problem you are having? You can issue SELECT FOR UPDATE, as you already said.
Quote:
Originally Posted by
pippo42
In case of a problem, there are usually knowledgeable people who reply helpfully and very quickly.
Yes but they like the question to be asked clearly. The more paragraphs (above 2-3) you write in your posts, the less answers you will get :) Answering your own posts leads to that too - i.e. I read mostly these threads that haven't been replied.
Quote:
So there is no way to build a normal, reliable database application.
This is just trolling. It's easy to throw accusations, it's harder to find humility to look for problems in your own code.
Quote:
The examples are numerous; QSqlRelationModel that does not handle left outer joins, QSqlTableModel that does not allow multiple sort fields and many others plus some strange things that occurs for which no one seems to have an aswer.
These are models that are meant to work for 90% of the people in 90% of the cases. Qt is not dedicated to database programming, remember that. If you're so good in C++ then subclassing proper classes and adding support for what you want shouldn't pose a problem.
Quote:
There are other difficulties: the lack of classical events that prevent the programmer to do the things he can do in other frameworks.
What do you mean by "lack of classical events"? You can use both native platform events and Qt wrapped (or Qt generated) events without any problems. I don't know if any of these fall into the category of "classical events" but for me it would seem so.
Quote:
But this is not really a problem. It become a nightmare if you try to do things you are used to in other frameworks but, if you follow its logic,it can deliver a solution that is more elegant.
It would be stupid to project habits from one framework onto another with completely different rules and architecture. Imagine going to a golf course with a tennis racket and blaming golf balls for lying on the ground all the time.
Quote:
I have really tried to learn, to follow its logic and not to rant because it was lacking features present in other frameworks. But I am dicovering that some things are plainly impossible.
There is a very simple answer for that, actually... RTFM! I assure you you can write reliable database applications in Qt if anything because Qt doesn't prevent you from sending any query to the database or using any library available for C++.