JDBTRG3.DLL failed after new trigger

[LTrepanier]

Hi,

I have a problem with one of my client JDBTRG dll. I created a new trigger in an existing table and it build into JDBTRG4.DLL. FAT client test is fine but I get the following error message in the jde.log from the Local Web client :

COB0000012 - GetProcAddress failed JDBTRG3.dll function _Q62001_FETCHAFTER@12 Error = 127

JDBTRG3.dll dumping don't show any of _Q62001_FETCHAFTER@12

ALL OCM mapping BSFN DEFAULT from DV900 are LOCAL and JDV900 are on my client's server logic.

Try to found something in BLC table but no trigger are in.

My question is why the build point to the JDBTRG4.DLL and my local web try to find the trigger to the JDBTRG3.DLL?

Our release are 9.0 tools 9.1.3.2.

Thank you kindly for your help!

 

[Zaki Ahmed]

Try running busbuild.exe and rebuild all dlls

 

[LTrepanier]

Hi Zaki,

Thank you for your answer but I already tried that without success. I forgot to mention it in my main message.

 

[reivilo78]

Hello/Bonjour

I would say the information to which DLL to go to is located in F9860.PARDLL

Now it is possible that you have two System databases, one on which F9860.PARDLL points to the JDETRG3 and one to the JDETRG4, and that JDE.INI points to one, and the JAS.INI to another.

Building Functions will use JDE.INI settings while using it on localweb will use JAS.INI.

 

[LTrepanier]

Hello reivilo78,

Thank you for your answer. I could not found JDBTRG3 or JDBTRG4 in F9860.PARDLL. We only have JDBTRIG for all table list in F9860.PARDLL. Do you know where I can find a list of JDBTRG1, 2, 3 and 4?

 

[reivilo78]

I've had the same problem as Luc Trépanier, 10 years later, but I didn't manage to solve it. I'd be interested if someone has the solution.

Here is what I found out :
In F9860.PARDLL there is always JDBTRIG for all tables.
When you build the table trigger, there is some logic (I guess inside busbuild.exe) that determines which DLL to build to (JDBTRG1/2/3/4). From my test I think the logic is based on the name of the table object, when i name my object Axxxxx, it gets built into JDBTRG1, when i name it Lxxxx (or i guess any letter after F) it gets built into JDBTRG4. When you name the table Fxxxx as a standard object it gets built into one of the libraries depending on what follows the F (I think), so it looks like the alphabetical rank determines it.

When you run the local web, data browser and run a query on the table though, there seem to be another logic, I'm not quite sure of that logic, but for example my table L43121, it is trying to find the function in JDBTRG2.dll. I created a L59TST table too and it got built into JDBTRG4.dll but when queried from databrowser, the function was searched from JDBTRG3.dll. At first i thought it bases itself on the system code which was 43 for L43121, but tried to change it to 90CA and it didn,'t change anything. My L59TST table had 01 as system code.
The problem occurs with table F9000 too, if you try to add a table trigger on it, it gets built into JDBTRG3 but is searched from JDBTRG4.

I tried to force the F9860.PARDLL to JDBTRG2 but it didnt change anything, it is still built into JDBTRG4