I guess that's one of the classical (legacy?) SQL Remote questions.
Usually, the operation from the sender is not sent back to that remote, in order to prevent send/resend cycles. That's a reasonable think, as it would usually be no good if the just INSERTed row would bounce back as an additional INSERT:)
However, there seem to be a few exceptions:
An UPDATE conflict is detected at the consolidated. Then the resulting row is sent to all subscribers, including the sending remote. AFAIK, that requires the usage of the special RESOLVE UPDATE triggers.
One uses the UPDATE PUBLICATION statement to explicitly move rows between subscribers. (However, I'm not sure if this really can move a row back to the sender.)
One uses a SQL Remote hook procedure to "delay the response" of an action from the SQL Remote "applying messages" phase to a later phase, e.g. with the sp_hook_dbremote_receive_end() hook. In such a phase, there is no more "current remote user", and each action gets send to all subscribers.
While re-thinking about an ASA 8.0.3.5574 SQL Remote setup, I have found unsure as when exactly such re-sending takes place.
So I would greatly appreciate more insight here - to fill/correct this list of exceptions:)
Source: Partly the NG entry "Re: Can Update Publication force an update?" by Rob Waywell, cf.news://forums.sybase.com:119/r9Unc0qM$GA.268@forums.sybase.com.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.