|
fire_triggers is a binary option: on or off. When off, triggers do not fire, but also you don't get any referential integrity checks or delete chaining. I'd like an option to turn off user-defined triggers, but preserve the RI actions. The reason is that we have two apps simultaneously accessing the same db. The old app is heavily dependent on triggers. The new app is designed to NOT require triggers. We'd like to disable the triggers for connections initiated by the new app, but not lose the RI actions. Pardon me if this is a repost: I posted yesterday but it didn't appear,probably because I had not yet validated my account here. (PS: Hola to Breck and my other old buddies from the team!) |
Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- numbered list: 1. Foo 2. Bar
- to add a line break simply add two spaces to where you would like the new line to be.
- basic HTML tags are also supported
Question tags:
question asked: 24 Mar '17, 09:44
question was seen: 1,522 times
last updated: 27 Mar '17, 10:14
Welcome to a Charter Member of [TeamPS]... I wish there was a way to add 10,000 points to your account in recognition :)
I don't suppose you want to add a line of code to the top of each non-ri trigger?
IF VAREXISTS ( 'this_is_the_new_app' ) = 1 THEN RETURN;
and CREATE that variable in a login procedure if the connection is coming from the new application?
The poster of that older FAQ would have probably seconded that suggestion:
http://sqlanywhere-forum.sap.com/questions/11984/on-delete-cascade-not-functioning
I do, too.
FWIW, the dbsrvX -gf server option might then have to be extended, as well. Note, it is a server, not a database option, so it effects all databases on the engine.
Yeah, we did something similar in sql server. would rather not revise our thousands of triggers on 750+ tables but maybe we will.
I am curious, how do you develop and test the code that has thousands of triggers. Or they are isolated well from each other.
> thousands of triggers
The old app is in Powerbuilder and has been in active development for more than 20 years. It's big. Because the design of the app does not funnel updates through a single update layer, triggers are used to assure certain business functions. We have extensive test suites, mostly regression tests using automation tools.