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 trigger, but from the app A, it
might work, but that does not solve my problem. App A is a black box to me,
and I cannot change it. That is why I need to have app B that will detect
that the change of the database occurred.
John Stanton-3 wrote:
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 no synchronization primitives. In my
suggested approach it would signal yourr semaphore to alert the
co-operating process that the database has changed.
BTW, if you are writing new programs do not use the archaic sqlite3_exec
call. Use sqlite3_prepare and sqlite3_stap.
If you have access to the Sqlite library you can compile in yuor custom
function so that it is always available. Then your trigger will signal
a change to the DB provided that it calls the function. You could also
patch Sqlite so that it signalled your semaphore each time it executed a
COMMIT. Then you would not have to touch process A.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
