S
smat-consulting
Guest
Yeap, sticking the logic into a .p and calling the .p persistently from the trigger-procedure would be how I would deal with this, too - especially, if all your code-base is procedural and your programmers are not familiar with OOABL. Many of us are so excited about new functionality, that they forget that the end result has to be maintainable by the folks who are regularly working the code... Not knowing what logic would be in the "if changed" THEN block, I suggested .i - If you're referencing specific fields you'll be better off with .i, rather than trying to make everything dynamic - just my preference... If you use the persistent procedure route, it is of course important not to forget to include some logic that checks if the procedure is already running, and if so just use this instance, rather than start a new one. Otherwise you won't get the performance benefit of not having to startup the .p every time the trigger is executed. If the .p is getting larger, this is a significant improvement - in my experience... Generating code is sometimes the best path - as long as it is done with brains. I generate the whole application - the specific stuff, that is. All the logic that can be extracted is extracted, thus not generated but reused. And all the customizable stuff is separated out as well, so you don't loose your manually done work when you have to regenerate... Whether you generate the trigger-files or type them manually, you'll end up with two files per table... Of course, if auditing is fulfilling your purpose, and if it is not an extra cost (as so much in Progress is), this might be the easiest route - definitely worth looking into...
Continue reading...
Continue reading...