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:
ASKED:
November 8, 2007 4:27 PM
UPDATED:
February 20, 2010 10:43 AM
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