Je développe une application clients/serveur en .NET sur une base de données
SQL Server.
L'architecture est assez simple, il y a un serveur possédant la base de
données centrale et plusieurs clients peuvent s'y connecter. Toutefois les
clients peuvent travailler en mode déconnecté (ils ont une copie de la BD
sur leur poste) et demander à synchroniser *certains* enregistrements avec
le serveur.
La synchro se fera principalement par l'entremise de procédures stockées .
Lorsqu'un utilisateur demande un synchronisation, il faudrait qu'aucun autre
utilisateur ne puisse modifiée les données impliquées dans cette synchro.
Ma question est donc la suivante, est-ce qu'une transaction ayant un
IsolationLevel de type SERIALIZABLE serait appropriée pour ce type de
travail ?
Si oui, comment bien ciblée les tables/enregistrements qu'ils faudra
"lockés" ?
Merci!
--
Cordialement
Yanick Lefebvre
MVP pour Visual Basic
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred BROUARD
Zoury a écrit:
Bonjour à tous! :O)
Je développe une application clients/serveur en .NET sur une base de données SQL Server.
L'architecture est assez simple, il y a un serveur possédant la base de données centrale et plusieurs clients peuvent s'y connecter. Toutefois les clients peuvent travailler en mode déconnecté (ils ont une copie de la BD sur leur poste) et demander à synchroniser *certains* enregistrements avec le serveur.
La synchro se fera principalement par l'entremise de procédures stockées .
Lorsqu'un utilisateur demande un synchronisation, il faudrait qu'aucun autre utilisateur ne puisse modifiée les données impliquées dans cette synchro.
Ma question est donc la suivante, est-ce qu'une transaction ayant un IsolationLevel de type SERIALIZABLE serait appropriée pour ce type de travail ?
oui si tu es sur de ton coup à chaque fois, c'est à dire que chaque client n'ait la possibilité de modifier que sur la partie des information qui le concerne, sinon on se retroue devant les mêmes problématique que la réplucation de fusion.
Si oui, comment bien ciblée les tables/enregistrements qu'ils faudra "lockés" ?
rien à vérouiller c'est la transaction qui s'en charge sinon, les transactions ne servirait à rien !!!
A +
Merci!
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Zoury a écrit:
Bonjour à tous! :O)
Je développe une application clients/serveur en .NET sur une base de données
SQL Server.
L'architecture est assez simple, il y a un serveur possédant la base de
données centrale et plusieurs clients peuvent s'y connecter. Toutefois les
clients peuvent travailler en mode déconnecté (ils ont une copie de la BD
sur leur poste) et demander à synchroniser *certains* enregistrements avec
le serveur.
La synchro se fera principalement par l'entremise de procédures stockées .
Lorsqu'un utilisateur demande un synchronisation, il faudrait qu'aucun autre
utilisateur ne puisse modifiée les données impliquées dans cette synchro.
Ma question est donc la suivante, est-ce qu'une transaction ayant un
IsolationLevel de type SERIALIZABLE serait appropriée pour ce type de
travail ?
oui si tu es sur de ton coup à chaque fois, c'est à dire que chaque client n'ait
la possibilité de modifier que sur la partie des information qui le concerne,
sinon on se retroue devant les mêmes problématique que la réplucation de fusion.
Si oui, comment bien ciblée les tables/enregistrements qu'ils faudra
"lockés" ?
rien à vérouiller c'est la transaction qui s'en charge sinon, les transactions
ne servirait à rien !!!
A +
Merci!
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Je développe une application clients/serveur en .NET sur une base de données SQL Server.
L'architecture est assez simple, il y a un serveur possédant la base de données centrale et plusieurs clients peuvent s'y connecter. Toutefois les clients peuvent travailler en mode déconnecté (ils ont une copie de la BD sur leur poste) et demander à synchroniser *certains* enregistrements avec le serveur.
La synchro se fera principalement par l'entremise de procédures stockées .
Lorsqu'un utilisateur demande un synchronisation, il faudrait qu'aucun autre utilisateur ne puisse modifiée les données impliquées dans cette synchro.
Ma question est donc la suivante, est-ce qu'une transaction ayant un IsolationLevel de type SERIALIZABLE serait appropriée pour ce type de travail ?
oui si tu es sur de ton coup à chaque fois, c'est à dire que chaque client n'ait la possibilité de modifier que sur la partie des information qui le concerne, sinon on se retroue devant les mêmes problématique que la réplucation de fusion.
Si oui, comment bien ciblée les tables/enregistrements qu'ils faudra "lockés" ?
rien à vérouiller c'est la transaction qui s'en charge sinon, les transactions ne servirait à rien !!!
A +
Merci!
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Zoury
ok merci! :O)
-- Cordialement Yanick Lefebvre MVP pour Visual Basic
ok merci! :O)
--
Cordialement
Yanick Lefebvre
MVP pour Visual Basic
-- Cordialement Yanick Lefebvre MVP pour Visual Basic
bruno reiter [MVP]
le réplication n'aurait-elle pas été plus simple et adaptée?
br
"Zoury" wrote in message news:uA$
Bonjour à tous! :O)
Je développe une application clients/serveur en .NET sur une base de
données
SQL Server.
L'architecture est assez simple, il y a un serveur possédant la base de données centrale et plusieurs clients peuvent s'y connecter. Toutefois les clients peuvent travailler en mode déconnecté (ils ont une copie de la BD sur leur poste) et demander à synchroniser *certains* enregistrements avec le serveur.
La synchro se fera principalement par l'entremise de procédures stockées .
Lorsqu'un utilisateur demande un synchronisation, il faudrait qu'aucun
autre
utilisateur ne puisse modifiée les données impliquées dans cette synchro.
Ma question est donc la suivante, est-ce qu'une transaction ayant un IsolationLevel de type SERIALIZABLE serait appropriée pour ce type de travail ? Si oui, comment bien ciblée les tables/enregistrements qu'ils faudra "lockés" ?
Merci!
-- Cordialement Yanick Lefebvre MVP pour Visual Basic
le réplication n'aurait-elle pas été plus simple et adaptée?
br
"Zoury" <yanick_lefebvre@hotmail.com> wrote in message
news:uA$RmX1wEHA.3668@tk2msftngp13.phx.gbl...
Bonjour à tous! :O)
Je développe une application clients/serveur en .NET sur une base de
données
SQL Server.
L'architecture est assez simple, il y a un serveur possédant la base de
données centrale et plusieurs clients peuvent s'y connecter. Toutefois les
clients peuvent travailler en mode déconnecté (ils ont une copie de la BD
sur leur poste) et demander à synchroniser *certains* enregistrements avec
le serveur.
La synchro se fera principalement par l'entremise de procédures stockées .
Lorsqu'un utilisateur demande un synchronisation, il faudrait qu'aucun
autre
utilisateur ne puisse modifiée les données impliquées dans cette synchro.
Ma question est donc la suivante, est-ce qu'une transaction ayant un
IsolationLevel de type SERIALIZABLE serait appropriée pour ce type de
travail ?
Si oui, comment bien ciblée les tables/enregistrements qu'ils faudra
"lockés" ?
Merci!
--
Cordialement
Yanick Lefebvre
MVP pour Visual Basic
le réplication n'aurait-elle pas été plus simple et adaptée?
br
"Zoury" wrote in message news:uA$
Bonjour à tous! :O)
Je développe une application clients/serveur en .NET sur une base de
données
SQL Server.
L'architecture est assez simple, il y a un serveur possédant la base de données centrale et plusieurs clients peuvent s'y connecter. Toutefois les clients peuvent travailler en mode déconnecté (ils ont une copie de la BD sur leur poste) et demander à synchroniser *certains* enregistrements avec le serveur.
La synchro se fera principalement par l'entremise de procédures stockées .
Lorsqu'un utilisateur demande un synchronisation, il faudrait qu'aucun
autre
utilisateur ne puisse modifiée les données impliquées dans cette synchro.
Ma question est donc la suivante, est-ce qu'une transaction ayant un IsolationLevel de type SERIALIZABLE serait appropriée pour ce type de travail ? Si oui, comment bien ciblée les tables/enregistrements qu'ils faudra "lockés" ?
Merci!
-- Cordialement Yanick Lefebvre MVP pour Visual Basic
Zoury
très possible.. n'ayant seulement qu'une vague idée de ce que c'est et n'ayant pas obtenu les heures tant convoitées pour bien étudier les possibilités qui s'offraient à nous, je n'ai pu me renseigner à ce sujet...... :O/
-- Cordialement Yanick Lefebvre MVP pour Visual Basic
très possible.. n'ayant seulement qu'une vague idée de ce que c'est et
n'ayant pas obtenu les heures tant convoitées pour bien étudier les
possibilités qui s'offraient à nous, je n'ai pu me renseigner à ce
sujet...... :O/
--
Cordialement
Yanick Lefebvre
MVP pour Visual Basic
très possible.. n'ayant seulement qu'une vague idée de ce que c'est et n'ayant pas obtenu les heures tant convoitées pour bien étudier les possibilités qui s'offraient à nous, je n'ai pu me renseigner à ce sujet...... :O/
-- Cordialement Yanick Lefebvre MVP pour Visual Basic
