Home/ Questions/Q 7056551
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T03:52:50+00:00

Strange behavior in our receive locations : RL_REPRESENTATIVE is waiting for a notification from

  • 0

Strange behavior in our receive locations:

RL_REPRESENTATIVE is waiting for a notification from the REPRESENTATIVE table (fields: (PK)id, fname, lname, etc).

RL_CLIENT_REPRESENTATIVE is waiting for a notification from the CLIENT_REPRESENTATIVE table (fields: (FK)id_rep, (FK)id_client).

When both of the locations are active and I commit a change in the CLIENT_REPRESENTATIVE.id_rep table I get a couple of warnings (apparently from RL_REPRESENTATIVE).

The adapter "WCF OracleDB" raised an error message. Details "System.InvalidOperationException: The notification query returned an error. Info="Error". Source="Data". Type="Change".
   at Microsoft.Adapters.OracleDB.OracleDBInboundContract.Notification_TryReceive(OracleCommonExecutionHelper executionHelper, Message& wcfMessage)
   at Microsoft.Adapters.OracleDB.OracleDBInboundContract.TryReceive(TimeSpan timeout, Message& message, IInboundReply& reply)
   at Microsoft.ServiceModel.Channels.Common.Channels.AdapterInputChannel.TryReceive(TimeSpan timeout, Message& message)
   at System.ServiceModel.Dispatcher.InputChannelBinder.TryReceive(TimeSpan timeout, RequestContext& requestContext)
   at System.ServiceModel.Dispatcher.ErrorHandlingReceiver.TryReceive(TimeSpan timeout, RequestContext& requestContext)".

and

The adapter "WCF OracleDB" raised an error message. Details "The WCF service host at address oracledb://d01-isis:1521/D01ISIS/Dedicated?CallingTable=REPRESENTATIVE has faulted and as a result no more messages can be received on the corresponding receive location. To fix the issue, BizTalk Server will automatically attempt to restart the service host.".

Otherwise the process that is activated by a modification in CLIENT_REPRESENTATIVE takes place with no problems.

(If I update, instead, id_client in CLIENT_REPRESENTATIVE – the error comes from another receive location that subscribes to notifications from the CLIENT table.)

Two further clues:

  • If I disable RL_REPRESENTATIVE, the warnings won’t appear.

  • If I update both CLIENT_REPRESENTATIVE.id_rep and REPRESENTATIVE.fname and commit both in the same transaction, the warnings won’t appear.

Note that there are no triggers in either tables and all my timeouts are set to almost 24 hours.

I suspect that the FK constraint does its job in a way that ends up sending a notification to the port but I never get the actual message that I’m supposed to receive.

Question: Is there a parameter in Oracle that controls this behavior? Have any Biztalk devs ever run into this problem?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    In the end, the solution was to change a flag in all the receive locations (NotifyOnListenerStart) to “false”.

    After further development, this solution was not complete – the errant triggering is occurring again – so I’m toggling the check to off until I (or someone else) finds the correct solution.

    Edit: This is a side-effect of the FK, changing its value seems to trigger a notification of a change in the table containing the PK (despite there not being any).

    • 0