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 th
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
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
rolle
Thanks! Something like that has already crossed my mind, but I was just
wondering if there was a way to achieve that goal using the existing
interfaces. Now, it looks like this solution is the only one to my problem.
Vladimir Stokic
John Stanton-3 wrote:
>
> If you have access to the Sqlite l
Vladimir Stokic wrote:
I agree that the solution with the semaphore is a very elegant one, but that
still does not solve the problem of having to define the custom function to
be called from the trigger over and over again. On the other hand, if the
function is not going to be called from the tri
I agree that the solution with the semaphore is a very elegant one, but that
still does not solve the problem of having to define the custom function to
be called from the trigger over and over again. On the other hand, if the
function is not going to be called from the trigger, but from the app A
If you use a semaphore it is independent of the processes currently
running and has nothing to do with a Sqlite connection. Your custom
function is called, signals the semaphore and exits. When the semaphore
is signalled the process waiting on it is activated.
In your example myfunc performs
On 10/13/07, Vladimir Stokic <[EMAIL PROTECTED]> wrote:
> I tried to do what you and Igor said, but I found out that it does not really
> work that way. I can make a user-defined function, but it stays active only
> while the current connection is open. It is not persisted in the "database".
> Fr
I tried to do what you and Igor said, but I found out that it does not really
work that way. I can make a user-defined function, but it stays active only
while the current connection is open. It is not persisted in the "database".
It does not work even if I try it from the same application. Here i
You could achieve your result by defining a semaphore. A custom
function in A would signal the semaphore and activate a thread in B when
the DB changed. The thread in B would be waiting on the semaphore Both
Unix and Windows implement semaphores in a similar manner.
A slightly higher level
Thanks for the advice. I appreciate it. However, I am rather new at IPC, so I
would like to ask you for a bit more detailed explanation. Is there some
c/c++ library that would make sending and IPC package over to app B
possible?
I do not want to do anything exotic here. A simple string sent over
Triggers won't help, either, because triggers run in the sqlite3
handle which, um, triggers. So if app A makes a change, the trigger
runs in app A, but not in app B.
You could have a custom function which the trigger invokes to send an
IPC over to app B.
-scott
On 10/12/07, Vladimir Stokic <[E
Hi there,
I would like to know if there is any way to access some external application
from within an SQLite trigger.
I have an application A that updates some rows in my SQLite database. What I
want is to be able to detect that the change has occured from the
application B, without having to u
13 matches
Mail list logo
