Thank you Tito, The application is actually supposed to run on a network and all copies will access the database file at some central location. I'm currently playing around with SQLITE_BUSY and SQLITE_LOCKED values and they work 90% of the time, but then sometimes they don't work for some reason and I get thrown out of the program.
This whole networking concept is proving to be a real pain to implement, but I really need it, so I'll keep banging my head against it :-) Dennis ----- Original Message ----- From: "Tito Ciuro" <[EMAIL PROTECTED]> To: "Dennis Volodomanov" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, October 30, 2003 12:11 AM Subject: Re: [sqlite] Checking the busy state Well, this is more an application implementation issue, not SQLite-only. 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
