We are planning to introduce triggers to achieve some integration work and to minimize customizations in Baan sessions.
Baan is running on Oracle (Unix). This is considered as one of the options.

Any Concerns/Advise/tips/traps I shoule be aware before jumping into this area.

Thanks

psivakumar@hotmail.com or psivakumar@husky.ca

It is strange that such an important topic is not getting any response.:confused:

Psivakumar,

I think you have queried the board on a very complex matter here. It would also be something alot Baan people/consultant have no or little experience with - correct me if I am wrong - , myself included. From a theoretical point of view, database triggers should work to update tables etc but I think it is very hard to estimate the impact on the application level. The data model of Baan really resembles a spaghetti structure and most people prefer to use the ways that Baan provides to manipulate the data rather then directly touching them on the database level. My advise would be to:
a. make sure you understand well the data structure and relationships you want to modify
b. test, test and test again.

Hope it is of some help!

Hi,

If you're creating triggers in Baan to update a non-baan table, I think it is safe but I do not recommend doing triggers on standard Baan tables


Best Wishes,
Zaid

First of all, have you considered using OpenWorld with the audit file interface for your application? Since Baan audit can track changes to a table, you can use this functionality to replicate data into a non-Baan table.

The biggest problem I have seen with the use of triggers is the maintenance impact. When database upgrades are done, new companies created, Baan tables are changed, etc. every consideration must be made regarding the impact on the triggers. And, in large environments where turnover or consultants are the norm, documentation is imperative. This is the third question I always ask when working with a customer on upgrades (1) version, (2) size of database, (3) use of triggers, (4) ...

The second major problem is the potential performance impact of the trigger. Depending on the number of triggers and the complexity of the associated action, this can make a huge difference in performance. As the completion of the trigger now is a portion of the transaction, transactions may take longer to return from the database commit. I have customers using trigger based applications that have resulted in having to double the CPU resources on the system to achieve the previous level of performance. Make sure you do extensive benchmarks in an environment similar to your production data (size of data and system resources) before going live.

Maintenance and Performance are the top two concerns.

If you have any further questions, let me know.

-- Jim

If you use database link with your trigger, it's good to use a file as a result of a triggering. We have had a trigger based on baan table and linked to an external instance.. Now when this link was broken, it was inbossible to work with Baan. now it's changed to file based operation and it's working ok...