You seem to have a habit of inventing bogus SQL and then, when it doesn't work, ask for the correct form on here. If I was the forum police I would suggest reading some freely available on-line documents, but since I'm not.
I think so checking possible cases of any sqlite operation should not be called as bogus. Where ever I am not sure I will ask expert help & I have got all the time right answers. With my politeness I do not want to discuss this topic here. If you have any specific concern please send mail separately to me I will reply accordingly. SQL is not a flow-control language, it makes adjustments to (or extractions from) datasets based on relational parameters, some of which makes it seem very very clever (and indeed I contend that it is quite clever), but it still isn't a flow-control specification. This is Ok. I understood & used same for test.DROP TRIGGER IF EXISTS trigger_name If I may ask, how on Earth did you end up having a Query whereby the creation (or deletion) of entire Triggers becomes part of the data-execution-logic? Maybe explain the first principle you wish to achieve and we could suggest how to best get there (as many have done here already). *Let me explain:* I am checking the case where database tables are created by different application. I am sure different application may not check available trigger name in all tables before creating new trigger. *Question:* What happen when same trigger name is used by two different tables in database and drop trigger query get executed.Find below statement : CREATE TRIGGER TestTrigger AFTER INSERT ON TestTbl1 BEGIN SELECT Trigger_notifier_function();END CREATE TRIGGER TestTrigger AFTER INSERT ON TestTbl2 BEGIN SELECT Trigger_notifier_function1();END DROP TRIGGER IF EXISTS TestTrigger Please correct me if my question is wrong. Note: Trigger logic will be different but trigger names are same. On Fri, Nov 1, 2013 at 5:36 PM, RSmith <rsm...@rsweb.co.za> wrote: > You seem to have a habit of inventing bogus SQL and then, when it doesn't > work, ask for the correct form on here. If I was the forum police I would > suggest reading some freely available on-line documents, but since I'm not > - here's an attempt at answering the question: > > SQL is not a flow-control language, it makes adjustments to (or > extractions from) datasets based on relational parameters, some of which > makes it seem very very clever (and indeed I contend that it is quite > clever), but it still isn't a flow-control specification. > > You will need to decide in your program code whether a Trigger or Index or > Table needs to exist or not, and from there instuct SQL to make it or drop > it. > > If I may ask, how on Earth did you end up having a Query whereby the > creation (or deletion) of entire Triggers becomes part of the > data-execution-logic? Maybe explain the first principle you wish to > achieve and we could suggest how to best get there (as many have done here > already). > > > > > On 2013/11/01 13:53, techi eth wrote: > >> How to drop trigger from specific table with condition around? >> >> >> >> I tried this but got syntax error. >> >> DROP TRIGGER trigger_name From tbl_name = TestTbl WHERE <Condition>; >> >> Thanks >> ______________________________**_________________ >> 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<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
