0

Why does the ad_zd_table.upgrade function (used to notify editioning of modifications in a table schema) automatically change the database triggers to point at the # view of that table? (In our case the result is that the triggers stop firing. I checked and they are editioning views that in theory support triggers, but they aren't working.) Is there a way to work around this problem?

0

I believe now this is by design. The solution is to point the source code for insert/update/delete statements at the editioned # view of the table. Then the triggers work. Alternately, you can create a synonym and point the insert/update/delete statements at the synonym. I'm not sure which is a better solution--although everything I see on the web is recommending the synonym approach. (Specifically putting the synonyms in the APPS schema. You can't put a synonym with the same name as the table in the same schema as the table, but I'm not sure why the APPS in particular is recommended, or why the synonym approach is recommended. If anyone knows the answer to that please comment.)

For more info: Oralce: Why Do Triggers on Editioning Views in My Custom Schema Fail?

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.