Yes, but how do I know in the PHP fired by the trigger what's the PHP context of his "parent"?.
Let me explain it. Inside the trigger I excute something like select test(); where test is a registered php function. When the trigger fires, the php function gets called, but the first thing I need to have is a database handler. Right know, the first thing I do in that test php is: $dbh = new PDO('sqlite:mydb.sqlite'); so that creates a new (an different) context, then if I try to: $res=$dbh->query("update set field=1 from same_table_that fired_the trigger"); I run in a deadlock, the first trigger is locking the table, and I'm waiting for that trigger to relese the lock. This will only end by time-out with the error "Database locked". so, how can the php fired by a trigger knows whats the php sqlite context of its caller?? thx again 2009/8/31 Kees Nuyt <k.n...@zonnet.nl> > On Mon, 31 Aug 2009 11:58:42 +0200, Alejandro Ruiz-Oriol > <aruiz...@itelsys.com> wrote: > > >I've been doing some further reading and I think that I already have the > >answer and it's "No, no way to avoid this". > > > >As far as I've read, when you start any update function, SQLite makes an > >exclusive write lock to the table. As far as I'm excuting from inside an > >update trigger, the database is "exclusivily write locked", so if that > >trigger tries to write to the DB, we will end up in a deadlock. > > > >The only thing that can "save" me from this behavior is if there is > someway > >to tell SQLite that the update is over, before the trigger finished. > > > >I've tried to put a commit inside the trigger, but I get a "syntax error". > > > >I'm working in to aporaches to the workarund. One i ssplit the table in > two > >(due to the logic of my aplication, maybe I can do this, cause the files > >updated by the trigger can have some kind of logic that I can use to split > >the table in 2 different tables). The other is to start a background php > >task that wait till the DB lock is released and then, tries the insert. > > > >Any suggestion? > > I think the registered callback function runs in the same > context as the php script that created the first conection, > and it should use that conenction, instead of creating a > second connection. > It's just a suggestion. I didn't try this myself. > -- > ( Kees Nuyt > ) > c[_] > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > 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