In light of my problems with java triggers (see other post http://www.psdn.com/library/thread.jspa?threadID=8202&tstart=0), I decided to pursue schema triggers, aka procedure triggers for openedge 10.1b. First of all I am developing on an evaluation version of openedge. When I run data dictionary I get the message: Note: Because of the version of OpenEdge you are using, the dictionary is in read-only mode.
If I proceed I can view the triggers, but since it is read-only I cannot make any changes. If I add the -rx startup option, data dictionary opens with no error message, but when I click the "Triggers" button within the "Table Properties" window, nothing happens. I see, however, that a .dct file gets created in the db directory whose contents state: ** You cannot run programs that access data in this PROGRESS version. (724).
QUESTION1: Is there anyway I can use the data dictionary in light of these errors to create the schema triggers?
QUESTION 2: Second related question is, can I just create my own *.p file with the 4gl code in it and use the progress sql explorer to insert these procedures into the database so as to skip the headache getting data dictionary to work correctly?
I would greatly appreciate any input, suggestions, or comments. Thank you.
Message was edited by:
Tom lerma
If you're just experimenting, then use session triggers inside a persistent procedure.
Thanks for the comment. Unfortunately, I will need to use these in a production environment. I just need to create them and test them in my development environment first, which right now happens to be the eval version.
As long as the session triggers you code are self-contained, the behavior's close enough.
And if your development env is currently the eval version, then what are you using for a real development env?
Just to throw in a couple of thoughts ....
I don't know why you have that limit in the eval. I have been hoping a PSC person would pop in and clarify. It seems silly to keep someone from making DB triggers when they can otherwise access full development capabilities. Perhaps it is a question of the installation or path by which you are getting there since it seems like an odd limitation on an otherwise pretty open tool.
Which said, one also has to note that the purpose of the eval is to evaluate, not to build code for a production environment. If you are building code for a production environment, you should have a real development license. If this is a question fiddling around with a new release while production is still on an older release, it is legitimate to upgrade just the development environment and even to have both versions installed at the same time. Technically, there is a time period for the overlap, but I know a lot of people who keep old versions around to support customers on old versions.
And, of course, there is a question about whether you should be using schema triggers in the first place. DB-side triggers and stored procedures were developed initially for a combination of enforcing relational integrity (always a good thing) and for improving performance by moving processing to the server in the early days of client/server. These days, however, architecture is about layers. With a layered architecture, the data access layer can be on the same machine as the database, thus providing the performance, and in that context it is really much better to put all of the the logic in one place, rather than putting some of it in triggers and some in the DA access layer code.
I would note that, unlike SQL stored procedures, all ABL triggers are run by the client, not the server.
So there's no real difference between schema and session triggers in terms of where they're run.