.r code in a database trigger

[franklin1232]

I am not a 4GL expert by any strech of the imagination, but I have written some simple procedures and I have one that no longer works. Our ERP vendor (epicor) has put a database trigger on the write of the shiphead table that wasn't there before. The trigger is stored in the database folder under trg\shiphead\write.r.

The error I receive now is "Can't find TRG\Shiphead\write.p" That makes sense because the file is write.r I haven't work much with .r code but this is a common theme in the database everything looks for .p but the ERP is all .r

How can I work around this? I also have concerns as to what the trigger is doing. Can I find out what the code does? I would guess only Epicor can tell me that.

 

[franklin1232]

Can I use the DISABLE-TRIGGERS some how to keep this error from coming up. I notice in the data administrator the trigger is pointed to the .p file as well. How does the ERP application force it to run the .r

 

[samu fish]

You can try to override db triggers

You can write your own trigger which overrides the stored trigger if it is overridable (which I doubt since the initial value is not overridable).

on write of shiphead override do:
/* nothing */
end.

your code goes here

Maybe You really should adjust your PROPATH so that trigger procedures will be found? On *nix machines program names are case sensitive and in Your post I saw capital letters in file names. Check that the programs really exists with those path names.

There is no problem calling triggers (or any other program) with .p extension. Progress will use compiled version if it exists.

 

[franklin1232]

Since the database design is not mine and I am leary of making chages to it. What would be the safest way?

Some addtional info: I opened the table with Data Dictionary and checked the trigger path on the ShipHead table. When I click on the trigger button I get an error stating that db/trg/shiphead/write.p does not exist. Couple of things I see hear. In the actually directory it is WRITE.r not write.p. The other is my propath. Since the path to the triggers isn't complete I will verify my propath. Can I change that at run-time.

 

[franklin1232]

Well I fixed the propath problem, but the write.r in the database trigger is looking for a shared variable. Anything I can do about that.

 

[samu fish]

Shared variables in trigger procedures

This is what you want to do: tell Epicor it is a bad bad thing to have shared variables especially in triggers!

In the mean time you may be able to find out from the error messsage what variables are needed and define those in your procedure.