Bonjour,

J'ai une question par rapport au fonctionnement des transactions dans un système de réplication.
Je m'explique, j'ai une procédure stockée qui se charge de nettoyer des doublons "fonctionnels" de plusieurs tables (cette procédure permet de rattacher les éventuelles relations d'un doublon à l'objet "original").

Le rattachement peut provoquer des erreurs SQL (violation d'unicité, contrainte d'intégrité référentielle... etc.), j'ai donc ajouté un paramètre "dryMode" à ma procédure stockée. Ce paramètre @dryMode, lorsqu'il vaut "true", permet de faire remonter les erreurs et permet de faire un ROLLBACK de ma transaction.
Si le paramètre @dryMode est à "false", des ordres adéquats sont exécutés pour ne pas provoquer d'erreurs et la transaction est "COMMITÉE".

1ère question :
Le "Transaction Mode" de la procédure stockée est "UNCHAINED", et j'ai lu sur internet (http://infocenter.sybase.com/help/in...g/sqlug855.htm en bas de la page) que dans ce mode-ci, uniquement les ordres DELETE sont "rollbackés" (il peut y avoir des INSERT ou UPDATE dans ma procédure). J'ai fait qq tests de ma procédure stockée, et les ordres INSERT et UPDATE ont l'air bien "rollbackés", qui croire ?

2ème question :
Autre interrogation, il y a un Replication Server qui se charge de la réplication,
et l'ordre dans lequel sont exécutés les ordres SQL est important pour ne pas affecter les contraintes d'intégrité de la base.
Les ordres exécutés dans la procédure stockée (donc dans la même transaction), lorsqu'il y a un commit, sont-il "répliqués" dans une seule et même transaction également ? Y a t-il des optimisations de la transaction ?

La procédure stockée qui fonctionne bien sur l'ASE "principal" provoque parfois des violations de contrainte sur l'ASE répliqué, d'où mon interrogation quant au fonctionnement des transactions via la réplication ?

Merci d'avance,

A+