[//]: # "Could not save the adapter notification: ‘insertMarketingNotifiy’.
[ART.116.3023] Adapter Runtime (Notification): Unable to update notification TestPackageNotification.specification.notification:insertMarketingNotifiy.
java.sql.SQLSyntaxErrorException: [SoftwareAG][Oracle JDBC Driver][Oracle]ORA-00942: table or view does not exist
com.wm.pkg.art.error.DetailedServiceException: [ART.116.3023] Adapter Runtime (Notification): Unable to update notification TestPackageNotification.specification.notification:insertMarketingNotifiy.
java.sql.SQLSyntaxErrorException: [SoftwareAG][Oracle JDBC Driver][Oracle]ORA-00942: table or view does not exist."
webMethods 10.15 free trial/jdbc adapter notification used and **** level:
After creating an adapter notification(LOCAL_CONNECTION) for a db table MARKETING, I am unable to save the notification and receiving the error as – Unable to update notification TestPackageNotification.specification.notification:insertMarketingNotifiy.:
The error indicates you have a missing table. Adapter notification service creates a staging table for getting/keeping track of the changes. The credentials you are using in adapter connection must have the permissions to create, update, delete tables because of this. Can you verify if you have those permissions?
@engin_arlak has provided good info for resolving this notification.
You might consider using the BasicNotification instead of the Insert/Update/DeleteNotification types.
The Insert/Update/DeleteNotification types are convenient because they create the DB objects (trigger, buffer table) for you. And for BasicNotification you need to manually create them in the DB.
Be aware, though:
The ability of the adapter to create/drop DB objects requires DB permissions (as @engin_arlak notes) that DB teams may not be willing to grant to an application.
When the Insert/Update/DeleteNotification is disabled, the DB objects are dropped. If someone disables the notification, intentionally or otherwise, events can be missed/lost.
BasicNotification requires a one-time set up in the DB. Suspending/disabling the notification has no impact on the DB objects. Downside is that when a notification is retired, the DB objects must be manually dropped.
Our convention is to only use BasicNotification. It can be used for insert, update and delete actions (the trigger is what controls what DB actions get put into the buffer table – e.g. before delete, after update, etc.) You may want to consider the same approach.