There are probably many possible solutions, but one I would implement is something like this:
1) Keep track of the db timestamp. That would let you know if something has changed.
2) This "something" is (please people correct me if I'm wrong) very difficult, if not impossible to determine, unless you query again for the data and compare it with your own modified version. In order to do that, you could implement an app-wide notification to let the app and its threads (in case it's multithreaded) know that the db has changed.
3) Each window, query object, whatever, displaying db data should then query the db again. This could be done by caching the query, for example. Then, it's a matter of executing the statement and retrieve the results.
4) After that, traverse the results and compare it with your modified version, for example. In case of a conflict, present the user with some dialog, etc. If no conflict occurs, you can save the data.
Of course, there are other issues that can crop up, like: what if the row was changed again after you retrieved the results, but before you saved? You could have more modified records which haven't been taken into account when you queried the db after the notification. Synchronization issues can be very messy, as you can see. My 'solution' is not bullet-free, I know. If other people care to present their views, I'd be very interested.
Regards,
-- Tito
On 29 oct 2003, at 12:08, Dennis Volodomanov wrote:
Yes, that's possible, but then I wouldn't know if I need to update the whole
database (if something was deleted) or just one row if it was updated and it
could make a difference (time-wise).
I was thinking of trying out the approach of creating a special table, for
example: network(busy,action,name) and then before a transaction write to
that table the values and after a transaction clear those values. Before
writing to this table though, I'd check for values that are already there
and if there're any values, then it's busy and that machine should wait,
otherwise just continue.
Does that sound reasonable? Are there any potential flaws in my logic here?
Thank you!
Dennis
----- Original Message ----- From: "Tito Ciuro" <[EMAIL PROTECTED]> To: "Dennis Volodomanov" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, October 29, 2003 9:49 PM Subject: Re: [sqlite] Checking the busy state
Hello Dennis,
On miércoles, octu 29, 2003, at 09:16 Europe/Paris, Dennis Volodomanov wrote:
That issue is, if I query a row before I want to change it, and I get some values, and reading from a database is allowed by all, even if the database is locked for writing, then how will I know that the database was changed?
One way is to keep track of the db's timestamp. You can check the value at key points and determine whether it has changed or not, then re-query as needed.
-- Tito
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
