Guys:

I'm a relatively-new SQLite user, but I'm luuuvin' it!   :)

My application is a mobile platform with a GUI that wants to display frequently-updated data in a database. The GUI is a separate process from the one providing the data, and is one of several consumers of that data.

I prefer not to poll for changes, because the system is performance-constrained. So instead, I'm using an AFTER UPDATE trigger in the data-generating process to launch a C function that posts to a semaphore. The GUI process is thus unblocked, and it then does a SELECT to get the data. I'm using the C/C++ API everywhere.

The problem I'm seeing is that the GUI process is getting stale data in its SELECT, unless it does a brief sleep between the sem_wait() and the sqlite3_exec(). Specifically, the value returned is the value immediately before the UPDATE. It's as if the trigger in the data-generating process and the query in the GUI process are both running before the new value is actually committed to the database file and/or whatever caches are in between.

Is this expected behavior? Is there a better workaround than simply sleeping after getting unblocked? Am I missing an entirely different--- and better--- way of synchronizing my GUI to the database?


Thanks!


b.g.

--
Bill Gatliff
[EMAIL PROTECTED]


-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to