What happens to replication if rows have been deleted on a target already? In a normal replicated world, the following sequence happens:


MAIN ASE: delete N rows issued 
RS:       delete N rows sent to replication target 
TARGET:   delete same N rows


However, what happens if the following sequence of events occurs?


TARGET:   delete N rows (before main server has them deleted)
MAIN ASE: delete N rows issued 
RS:       delete N rows sent to replication target 
TARGET:   No such rows to delete?!?!?!


What happens then?

Does the rep server fail? Does the main ASE transaction abort? Does everyone act like this never happened and replication worked (since end result is as if it did)?

P.S. Yes, I know, typically you shouldn't ever pull such a stunt and data should never be changed on replication target. And if not you should use "set replication off" on main server session. The question is "what happens if this does occur, in violation of 'should'".
What happens from a SAP/Sybase Replication Server (SRS) perspective?

Depends on SRS version and how the DBA's configured the SRS instance.



Prior to SRS 15.2 the 'empty' DELETE would cause no problems, ie, the DELETE would be issued against the target, no rows found/affected, and SRS would continue to process the next transaction.

The key here is that a DELETE statement that does not find any rows to delete merely completes, successfully (ie, without error), with @@rowcount=0.

NOTE: The same 'logic' applies to UPDATEs, INSERT/SELECTs and SELECT/INTOs that complete successfully but affect no rows.

NOTE: The same 'logic' applies to DML statements that complete successfully but affect a different number of rows.



With SRS 15.2+ a replication server error class was introduced with the primary emphasis being to notice when transactions affect a different number of rows in the target ... and when said issue occurs to raise an error (eg, 5185) and suspend the DSI connection.

Each transaction coming over from the source is tagged with the number of affected rows.  If the transaction, when applied to the target, affects a different number of rows then SRS will (by default) suspend the DSI and dump an error message to the errorlog.

The DBA can modify the default rowcount mismatch behavior by assigning a different action to the corresponding error number in the replication server error class (see the assign action command for more details).

Obviously (?) the DBA should research any rowcount mismatch errors to determine if they are ok/valid, or if they indicate an issue with the the target being out of sync with the source.



Other scenarios the DBA would want to investigate could include:


replicated stored procs that don't affect the same set of rows on the target
custom function strings that modify a transaction in such a was as to (explicitly) modify the number of affected rows in the target
lack of a primary key for a table




Keep in mind that while SRS is routinely used to keep a DR/backup database in sync with the primary database, SRS can also be used to:


distribute subsets of data (distribution model)
consolidate data (roll-up model)
maintain historical/audit data (eg, convert DELETEs/UPDATEs to save 'old' image of data in a history table)
propagate sub-/super-sets of data per application requirements


Net result is that the occurrence of rowcount mismatches may or may not be ok ... it all depends on the individual SRS environments.