User's Manual

Chapter 6. Principles of SQL Remote Design
♦ Conflicts A user updates a row. A second user updates the same row at
another site. The second user’s operation succeeds, and SQL Remote
allows a trigger to be fired (Adaptive Server Anywhere) or a procedure to
be called (Adaptive Server Enterprise) to resolve these conflicts in a way
that makes sense for the data being changed.
Conflicts will occur in many installations. SQL Remote allows
appropriate resolution of conflicts as part of the regular operation of a
SQL Remote setup, using triggers and procedures.
☞ For information about how SQL Remote handles conflicts as they
occur, see the following chapters.
Tracking SQL errors
SQL errors in replication must be designed out of your setup. SQL Remote
includes an option to help you track errors in SQL statements, but this option
is not intended to resolve such errors.
By setting the Replication_error option, you can specify a stored procedure
to be called by the Message Agent when a SQL error occurs. By default no
procedure is called.
❖ To set the Replication_error option in Adaptive Server Anywhere
1. Issue the following statement:
SET OPTION
remote-user.Replication_error
= ’procedure-name’
where remote-user is the user ID on the Message Agent command line,
and procedure-name is the procedure called when a SQL error is
detected.
❖ To set the Replication_error option in Adaptive Server Enterprise
1. Issue the following statement:
exec sp_remote_option Replication_error, procedure-name
go
where procedure-name is the procedure called when a SQL error is
detected.
Replication error
procedure requirements
The replication error procedure must have a single argument of type CHAR,
VARCHAR, or LONG VARCHAR. The procedure is called once with the
SQL error message and once with the SQL statement that causes the error.
89