I noticed that the JDBC adapter on wM 6.0.1 doesn’t drop the buffer table that it creates after I delete the Adapter Notification service.

From the 6.0.1 JDBC user guide:

“Before you delete an automatic notification, be sure that you first disable it. Otherwise the
trigger and buffer table created by the automatic notification will remain in the database.”

I wish they’d change the table-drop behavior with the automatic notifications, or at least make it an option you can disable. This has been a sticking point in the old JDBC adapter with some of my clients - you can’t disable the notification without losing any data currently in the buffer table.

I agree with you that an option to drop or not to drop the tables would be a great enhancement of the product. But I have learned that most of my clients do not want us to use webMethods to create the tables or triggers automatically anyway. Most clients want to have that functionality moved to their DBAs.

By creating the tables and triggers outside of the webMethods tool, and using the Basic Notification feature of webMethods, you get the capability of disabling the JDBC polling and the tables don’t get dropped. Also, your DBA gets better control of the table objects and where their data is stored in a database instead of the default tablespace, etc.

One thing you can do to get the best of both worlds, is to use Insert_Notification, and have it create the table and triggers automatically for you, then extract the scripts from the database using a tool like TOAD. Once you have the scripts, they can be modified by your DBA to his standards, and then the DBA can migrate them between environments.

This gives you the ability to generate the tables and triggers without having to know alot about SQL, but also gives the DBA the functionality they are looking for.

Absolutely true - for the most part production systems don’t use the automatic notifications anyway. It would still be nice to have the option, though.