Instead of using the resolve_conflict script for conflict resolution, you can call a stored procedure in the upload_update script. With this technique, you must both detect and resolve conflicts programmatically.
The stored procedure must accept all columns, including both the new (post-image) and old (pre-image) values.
The upload_update script could be as follows:
{CALL UpdateProduct( {ml o.id}, {ml o.name}, {ml o.desc}, {ml r.name}, {ml r.desc} ) } |
The UpdateProduct stored procedure could be:
CREATE PROCEDURE UpdateProduct( @id INTEGER, @preName VARCHAR(20), @preDesc VARCHAR(200), @postName VARCHAR(20), @postDesc VARCHAR(200) ) BEGIN UPDATE product SET name = @postName, description = @postDesc WHERE id = @id AND name = @preName AND description = @preDesc IF @@rowcount=0 THEN // A conflict occurred: handle resolution here. END IF END |
This approach is often easier to maintain than resolving conflicts with resolve_conflict scripts because there is only one script to maintain and all the logic is contained in one stored procedure. However, the code of the stored procedure may be complicated if the tables columns are nullable or if they contain BLOBs or CLOBs. Also, some RDBMSs that are supported MobiLink consolidated databases have limitations on the size of values that can be passed to stored procedures.
See:
Discuss this page in DocCommentXchange.
|
Copyright © 2010, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.0 |