Thanks for quick answer. Yes,I understand i may no be able do inter process communication but calling process can be register for call back (function register to sqlite3_create_function()) on trigger & do whatever required .
Cheers- On Mon, Jul 22, 2013 at 12:09 PM, RSmith <rsm...@rsweb.co.za> wrote: > There is no way to contact an unknown thread that may or may not be > running. This means that any thread you wish to speak to needs to be > registered somehow in some list and have a means of "listening" to you, > which in turn means SQLite (or indeed any other RDBMS) cannot simply notify > one or more other applications of something. > > You will need to register some function with SQLite which you can call in > a trigger (as Peter mentioned), but this function cannot be attached in a > different thread, i.e. you cannot have the function call the registered > code from one or more OTHER threads/applications than the one making the > database connection, so you will need to make your own code in which, if > the function gets called, it contains a mechanism for communicating it to > another instance or instances of itself, or indeed any other apllication > thread running in the OS which it somehow knows about and knows how to > contact. > > Another option is to have a continuous interrogation of some data table > which contains possible messages that one application may set and another > may check until there is something to read, then read it and act > accordingly. The caveat here is that one thread's DB connection may not > flush cached values for some time and it is IO intensive, depending on how > fast polling you are doing and how deterministic you need it to be. This > sort of communication (if it can be called that) is ok if you have a slow > non-deterministic one-way notification need. > > Personally, I prefer using a named pipe or socket connection on a local > machine/device to an application which serves the changed data. This is the > purpose pipes/sockets exist for (as opposed to a file system), and it makes > process visibility and debugging much easier. (Not to mention the enormous > ease with which it can later be scaled up to a multi-tiered networked / > internet system). The con here is that the serving application must be > alive and running all the time for anyone else to know the current data > state, although a last-known-state DB table can be pressed into service > here should this be a real problem. > > RDBMSes should never be in charge of communications. > > Have a great day! > > > PS: On Windows systems specifically you can also use the DDE service for > inter-application communications, it's a cheap and nasty solution, not my > favourite, but sometimes cheap and nasty is what is needed. Sockets work > cross-platform mostly and does not require much of an application change if > you do go multi-platform, just the socket layer itself adjusts. > > > > On 2013/07/22 07:32, techi eth wrote: > >> I want to create a trigger on INSERT & in trigger logic I want to notify >> other running executable in system. >> >> Can I do this using trigger operation? >> >> Example: >> >> Create table (); >> >> CREATE TABLE test ( >> >> ID INT PRIMARY KEY NOT NULL, >> >> NAME TEXT NOT NULL, >> >> ); >> >> >> >> CREATE TRIGGER Event_test1 AFTER INSERT >> >> ON test >> >> BEGIN >> >> <Notify to other process either by registered callback OR signal> >> >> END; >> >> >> Cheers >> >> Techi >> >> > ______________________________**_________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users<http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users> > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users