Your trigger can record the change notification in a separate table. So long as the system processing the change notifications cleans them up as it goes, this can be reasonably efficient.
-scott On 10/13/07, Vladimir Stokic <[EMAIL PROTECTED]> wrote: > > Spot on! I could monitor the change of the file, but, like you said, that > does not tell me _what_ changed, so I would still have to poll the database. > And yes, I would be looking for a single row change in a database of 30+ > tables with 75000+ rows each. > > > Trevor Talbot-2 wrote: > > > > A couple other things come to mind here, that might be relevant to > > what you're doing: > > > > * A trigger that has a "final" side effect, like signaling another > > process, will both have that effect early (before the transaction is > > committed), and will have that effect even if the transaction is later > > rolled back. > > > > * Since database modifications are serialized, the file is updated > > when a change is committed. You might be able to use the OS's > > notifications of file modification to determine when to check for data > > changes. Of course, this won't tell you _what_ changed, which might > > not help if you're only watching for a tiny item in a large database. > > > > > > -- > View this message in context: > http://www.nabble.com/Accessing-external-applications-from-within-SQLite-triggers-tf4614175.html#a13189402 > Sent from the SQLite mailing list archive at Nabble.com. > > > ----------------------------------------------------------------------------- > To unsubscribe, send email to [EMAIL PROTECTED] > ----------------------------------------------------------------------------- > > ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
