Discussion :

[AF_STjohn]

Bonjour à tous !

J'ai mis en place une réplication de type Merge avec un Publisher et plusieurs Subscribers.

J'aimerai savoir s'il est possible, via une requête SQL par exemple, d'envoyer une information de vérouillage d'une ligne d'une table à un moment M (par exemple, lorsqu'un utilisateur de mon application ouvre une fenêtre client, d'envoyer une information empêchant les autres Subscribers de modifier ce même client).

Si oui, comment faire ? Ma solution actuelle consiste à ajouter des champs "Lock" (booléen) et "UserLock" (pour l'identification du Subscriber), mis à jour dès que nécessaire. Le problème étant que si ce Subscriber se déconnecte du réseau, ce champ va rester à Lock à jamais ... Je suis obligé de faire un script pour nettoyer les locks régulièrement.

Quelqu'un voit une autre solution ?

Merci d'avance.

[Yad]

Pourquoi veux tu bloquer les autres abonnés ?

Il me semble que cette réplication gére très bien tout ça ... en effet, si 2 abonnés changent une même données à un même moment, SQL server sait très bien comment gérer ça tout seul ... au pire il y aura un conflit et tu as accès à l'utilitaire de résolution des conflits ...

Enfin, je ne sais pas, je ne suis pas un pro, moi je laisse faire le serveur et je ne rencontre pas de problèmes ...

[AF_STjohn]

Ben c'est très simple, si j'ai deux clients connectés en même temps au Publisher.

Le client A ouvre une fenêtre d'édition de la Table "Commande" (par exemple), et comment à éditer la commande 1.

2 secondes plus tard, le client B ouvre cette même fenêtre d'édition.

Le client A enregistre la modification, puis le client B. Les modifications du client A vont être écrasé (ou celle du client B selon la configuration du conflit) sans qu'aucune autre précaution ne soit prise.

Cela aurait pu être évité si le client B n'avait pas pu ouvrir la commande 1.

Je continue de chercher la meilleure solution :o, merci quand même.

[Yad]

Oui mais tes abonnés peuvent travailler en mode non connecté non ?

Et si ils changent en non connecté un enregistrement le Lundi mais ne se connecte que le Vendredi ? Que se passe t il ?

A mon avis tu te complique la vie ...

[AF_STjohn]

Je me complique peut être la vie mais je fais juste ce qu'on me demande de faire moi ! Si j'avais le choix j'aurais fait beaucoup plus simple !

S'il travaille en mode non connecté, là évidemment on ne peut que s'en remettre au Conflict Management fait par SQL Server !

[Yad]

Bon ... si on te le demande alors ... effectivement ...

Voyons ce que les pros vont répondre, c'est intérressant ...

[AF_STjohn]

Personne n'en pense quelque chose apparament !

[Yad]

Oui ... les réponses sur les réplications ne sont pas nombreuses ici ... mais c'est pas grave ... il faut bien commencer ...

Allez ... patience ...

[AF_STjohn]

Oui de toute façon je ne vois pas de possibilité de vérouiller une table (ou idéalement un champ d'une table) directement via la réplication ...

Cela passe forcément par un champ booléen dans ma table.

Enfin je n'ai rien trouvé quoi. Je vais partir sur cette solution, ça évitera déjà des conflits entre 2 clients connectés. Son principal désavantage est de m'obliger à mettre ce lock sur tout ce qui peut être utilisé par plusieurs clients ...

Je vais chercher, si quelqu'un s'y connait en vérouillage manuel de champ/table, qu'il n'hésite pas (promis j'arrête de vous embêter après ... au moins cette semaine ) !

[AF_STjohn]

Apparament il est possible de vérouiller une table ou même une ligne, mais dans le cas d'une Merge replication, il faudrait non pas vérouiller le client mais le Publisher.

Et là je vois pas trop. Mais mes recherches continuent.

[AF_STjohn]

Quelqu'un sait comment gérer manuellement les vérous ? Personne ?

[SQLpro]

Pour gérer manuellement les verrous : ajoute une clause WITH à chaquer table dans tes requêtes.

Cela dit ce que tu veut faire est le plus sûr moyen de bloquer le serveur et pourrir les données.

1) l'utilisation direct de verrous est FORTEMENT déconseillée
2) le blocage d'une resource pendant la réplication induit des temps de latence plus grand
3) une réplication fusion dans une base mal modélisée est le plus sûr moyen de se retrouver avec des conflits ingérables.

A +

[AF_STjohn]

Merci pour ta réponse. On va essayer de contourner le problème alors, en restreignant d'avantage les publications pour que les clients aient un minimum de données disponibles en commun.