DB Triggers and JPA
AS/400, iSeries, JPA, Spring, SQL Anywhere Studio/M-Business Anywhere/Avantgo, Toplink, Triggers, XFire
I have a physical file/table, on an iSeries, into which I drop a record containing UserID and Password. This action in turn fires a trigger that ends up calling the api QSYGETPH to verify the user's login credentials. This has been working for years under our previous architecture, wherein we inserted the record via SQL from a "normal" java program.
However, we recently switched our middleware architecture to Spring/XFire, using JPA with Toplink. Now, the record gets inserted, but the trigger doesn't fire. I have tried this with dao.persist, EntityManager.createQuery, and EntityManager.createNativeQuery. In all instances, the record gets dropped into the file, but the trigger doesn't execute. Yet, if I create a record manually with a utility like wrkdbf, the trigger works fine on the file.
Any help would be greatly appreciated.
R. Grimes
Software/Hardware used:
Software/Hardware used:
ASKED:
November 8, 2007 4:27 PM
UPDATED:
February 20, 2010 10:43 AM
Answer Wiki:
Seems to me if the trigger is working using another program or utility it isn't the trigger program logic that is wrong.
I would check the authority you might be adopting in the new application to see if that is the cause. We use trigger programs here but they all run under adopted authority to a user with all object authority.
To see all answers submitted to the Answer Wiki: View Answer History.
I’m using the same connection User ID and Password as worked on the old non-jpa architecture. Also, since I can see the record getting dropped into the database, there is obviously no problem with my write authority. It’s the db’s responsibility to detect a inserted record and fire the trigger. But, this is acting as though an insert via jpa is operating under stealth.
R. Grimes
I finally gave up on using a trigger program. Instead I decided to write a java class that uses ProgramCall from the com.ibm.as400.access package. I have ProgramCall execute an iSeries CLP program that, in turn, calls QSYGETPH and QSYRLSPH to validate the user credentials and return a valid/not valid flag. This seems to work just fine for what I’m doing.
R. Grimes
If you can demonstrate that the file insert happened and the trigger did not fire, that would call for an immediate problem report to IBM. Personally, I find it very unlikely. Most likely, the trigger logic is indeed incorrect or authority is inappropriate. If triggers failed to fire, IBM Support lines would be burning up.
Tom