Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

dealing with 7137 errors

2 posts in Replication Last posting was on 2010-12-23 08:19:06.0Z
Michael Philbrick Posted on 2010-12-23 00:42:16.0Z
Date: Wed, 22 Dec 2010 16:42:16 -0800
From: Michael Philbrick <mphilbrick@integraprise.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
Newsgroups: Advantage.Replication
Subject: dealing with 7137 errors
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 67.101.7.12
Message-ID: <4d129acf$1@solutions.advantagedatabase.com>
X-Trace: 22 Dec 2010 16:41:51 -0800, 67.101.7.12
Lines: 38
Path: solutions.advantagedatabase.com
Xref: solutions.advantagedatabase.com Advantage.Replication:433
Article PK: 1134285

We replicate a database with approximately 90 tables uni-directionally
for "backup" purposes in addition to a streaming backup. Every so often,
maybe once ever few weeks, we get a 7137 error and replication stops,
the queue table fills, etc.

Assuming that the lowest numbered record in the queue table is the one
that received the error that stopped replication, it is on a very simple
update of a table, using an SQL UPDATE statement.

The message in the ADS error log is "The SQL statement affected 0
records instead of 1 record."

The knowledge base states "During replication if an error occurs it will
stop replication. Errors such as 7137 which indicate that an unexpected
number of records were affected by the replication probably want to be
ignored."

It sounds like the error is harmless, but did the update already occur,
or did it not occur, and if not, why? Based on the table affected (there
is one that gets a large portion of these errors), the row was inserted
minutes if not hours before the update was done, so it is not an issue
of an insert being done right before an update. Also, it is not
conceivable that the application would pass a wrong record number for
the update as it is getting it from a query performed just prior. BTW,
all tables have an auto-increment field.

So, here are some of my questions:
1) is the lowest record number in the stalled queue the culprit, the one
that generated the entry in the ADS error log?
2) if we ignore the 7137 error does this record stay in the queue or is
the queue emptied?
3) do we have any idea if the update was really performed, or do I
assume that the error means that no update was done and the source and
target rows are now out of sync?
4) is there any way I can ignore the error so replication does not stop
and yet get the table and row ID (maybe through a trigger) so that I can
stop replication on that one table and either zap and repopulate it or
copy it from one database to another?


Joachim Duerr (ADS) Posted on 2010-12-23 08:19:06.0Z
From: "Joachim Duerr (ADS)" <jojo.duerr@gmx.de>
Subject: Re: dealing with 7137 errors
Newsgroups: Advantage.Replication
References: <4d129acf$1@solutions.advantagedatabase.com>
Date: Thu, 23 Dec 2010 09:19:06 +0100
User-Agent: XanaNews/1.19.1.269
X-Face: u2p+</,mb|Ah!x!/qxX5q0t:O~.<1&JzwNHYhSqcviY{~&|iDc"U.Je1A.ZeHR`d;;y#R
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 130.214.79.11
Message-ID: <4d130594$1@solutions.advantagedatabase.com>
X-Trace: 23 Dec 2010 00:17:24 -0800, 130.214.79.11
Lines: 42
Path: solutions.advantagedatabase.com
Xref: solutions.advantagedatabase.com Advantage.Replication:434
Article PK: 1134287


Michael Philbrick wrote:

>The message in the ADS error log is "The SQL statement affected 0
>records instead of 1 record."

it should be sufficient to check the 'MERGE' option for inserts and
updates on all of your articles.

>BTW, all tables have an auto-increment field.

Is this your primary identifier or do you compare all fields?

>1) is the lowest record number in the stalled queue the culprit, the
>one that generated the entry in the ADS error log?

yes.

>2) if we ignore the 7137 error does this record stay in the queue or
> is the queue emptied?

the queue is emptied. The error is ignored and the record is removed
from the queue.

>3) do we have any idea if the update was really performed,
>or do I assume that the error means that no update was done and the
>source and target rows are now out of sync?

depending on the numbers you see: 0 updated means 0 updated, 2 updated
(instead of one) means 2 updated;)

>4) is there any way I
>can ignore the error so replication does not stop and yet get the
>table and row ID (maybe through a trigger) so that I can stop
>replication on that one table and either zap and repopulate it or
>copy it from one database to another?

not that I know. It's not a conflict, so no trigger fires.

--
Joachim Duerr
Advantage Presales
check out my new ADS book on http://www.jd-engineering.de/adsbuch