JDBC Adapter Notificatin - Trigger not working!

Hi All,
I’m a newby to WebMethods. I’ve written a few applications so far and all seem to be working fine. I’m in the process of making a minor change to one of these existing apps. The problem I’m having is getting the trigger to work in my local environment. The original process is running in production with no problems. The only thing that has been changed is an additional database column was added and set up to be passed through the process. Everything works when I run the debug from the developers screen, but when I simply add a record to the database the trigger is monitoring I get no results. Nothing happens. Anyone have any idea why the trigger is’nt seeing the changes in the database?


Is the JDBCAdapter notification is enabled inorder to get your service triggerred?? After you modified table added/column does the notification service in sync and regenerated it? pls note…


Did you regenerate the adapter notification after making that change in database ?

The trigger is enabled and everything works from my workbench in debug. I’ve sync it a few times. But nothing seems to help. I appreciate the help. Thanks

This process doesn’t use an adapter notification. Just a trigger. I’ve rebuilt the trigger to make sure it was looking at the correct canonical view.

Without an adapter notification of some sort, nothing will fire unless you’ve written some DB polling facility yourself.

There are two triggers involved: a DB trigger and an IS trigger.

The DB trigger fires as configured by the trigger creation–before/after insert/update. This trigger reads the source table and writes entries into a buffer table.

The adapter notification polls the buffer table. When data is found, it is published on IS (either locally or via the Broker, depending upon your IS configuration).

The IS trigger will receive that published document and invoke the configured trigger service. That trigger service can do anything needed to process the event, including reading additional data from the source table or any other appropriate activity.

A change to the DB table definition, depending on how the change was done, may have dropped or disabled the DB trigger.

I usually recommend using Basic Notification for notifications to avoid the (minor) issues associated with the Insert/Update/Delete Notification types.

If your situation is different from what is assumed here, please advise.

How is your current trigger kicksoff when you say running debug/standalone mode in the developer…could you elaborate that test?? As explained above the triggers/notifications mechanism is the way to go.