Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Windows Windows Serveur SQL Serveur Sql Server 2000 : synchronisation de bdd distantes

Sql Server 2000 : synchronisation de bdd distantes

20 réponses
Avatar
Gautier Vincent
Amis de Newsgroup, experts en Sql Server, bonjour.

J'ai besoin de vos lumi=E8res sur la synchronisation de bdd=20
Sql server 2000 (V8) distantes.

C'est un peu long, mais explique bien ma situation...

J'ai un serveur Windows 2000 server, qui contient la bdd=20
de production Sql Server.
Plusieurs clients (portables et postes fixes) attaquent=20
cette base simultan=E9ment via un frontal Delphi, une=20
connexion ODBC et un lan TCP/IP.
OK pour cela.

Mon probl=E8me est quand les portables travaillent sur leur=20
bdd locale (identique =E0 celle de production),
mais avec des donn=E9es qu'ils modifient en clientelle.
=20
Dans ce cas, je fais (pas forc=E9ment de lien r=E9seau):

- 1 backup de la bbd de production
- puis 1 restore de cette sauvegarde sur la base locale du=20
portable (via le r=E9seau ou le t=E9l=E9phone avec Pc Anywhere).
Le portable a donc une base locale identique =E0 celle de=20
production et est autonome.

Pour synchroniser les modifications de la base locale du=20
portable et de la base de production du serveur,
je fais =E0 partir de la base de production du serveur :

- lecture via le r=E9seau des donn=E9es locales du portable=20
modifi=E9es <portable local>.<bdd locale>.dbo.tables
et int=E9gration dans la base de production du serveur, si=20
le portable est reli=E9 au r=E9seau
- backup de la base locale du portable et restore sur une=20
base secondaire du serveur (via le r=E9seau ou le
t=E9l=E9phone avec Pc Anywhere) si le portable n'est pas=20
reli=E9 au r=E9seau, puis int=E9gration des donn=E9es
modifi=E9es de cette base secondaire dans la base de=20
production du serveur

La base de production du serveur contient donc les donn=E9es=20
modifi=E9es sur le portable, mais le portable
n'a pas les donn=E9es qui ont =E9t=E9 modifi=E9es sur le serveur=20
par ses coll=E8gues. Donc, =E0 nouveau :

- 1 backup de la bbd de production du serveur
- 1 restore de cette sauvegarde sur la base locale du=20
portable (via le r=E9seau ou le t=E9l=E9phone avec
Pc Anywhere).
Le portable a donc maintenant une base locale identique =E0=20
celle de production

NB : instructions utilis=E9es, via le r=E9seau :
backup database [base esf] to disk =3D 'c:\ef\base esf'=20
with init, skip
restore database [base esf] from disk =3D 'c:\ef\base=20
esf'

Cette synchronisation fonctionne mais a les contraintes=20
suivantes :

- fastidieuse et lourde
- manipulations =E0 faire sur les deux postes (backup sur=20
l'un, restore sur l'autre si liaison par
PC Anywhere)
- lors d'un restore, l'utilisateur de connexion =E0 la bdd=20
reste mais n'est plus reli=E9 =E0 la bdd restaur=E9e.
Il faut le supprimer et le recr=E9er.

Je suis s=FBr qu'il y a une fa=E7on plus simple de=20
synchroniser 2 bdd distantes, sans passer par des backup,
des restore ou des Bulk copy (descente et remontage des=20
donn=E9es de tables via des fichiers texte) :

- copier directement les fichiers data et log d'une bdd=20
distance sur le serveur, et inversement (les
fichiers refusent d'=EAtre copi=E9) ?
- puis, les lier =E0 une bdd secondaire sur le serveur ?
- puis, int=E9grer les modifications de cette base=20
secondaire dans la base de production du serveur ?
- puis, =E9craser les fichiers data et log de la bdd=20
distance par les nouveaux fichiers de la bdd de
production synchronis=E9e (les fichiers refusent d'=EAtre=20
=E9cras=E9) ?


Merci d'avance de m'aider sur ce sujet =E9pineux.

Mr Gautier Vincent
T=E9l : 02 97 63 91 90
technique@espacefermetures.com
Signaler un problème avec ce contenu

10 réponses

Supprimer
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
1 2
Avatar
AXL
combien de table sont mise a jour par l'utilisateur itinerant ?

"Gautier Vincent" a écrit dans le
message de news: 0bf201c4a174$fcb07ec0$
Amis de Newsgroup, experts en Sql Server, bonjour.

J'ai besoin de vos lumières sur la synchronisation de bdd
Sql server 2000 (V8) distantes.

C'est un peu long, mais explique bien ma situation...

J'ai un serveur Windows 2000 server, qui contient la bdd
de production Sql Server.
Plusieurs clients (portables et postes fixes) attaquent
cette base simultanément via un frontal Delphi, une
connexion ODBC et un lan TCP/IP.
OK pour cela.

Mon problème est quand les portables travaillent sur leur
bdd locale (identique à celle de production),
mais avec des données qu'ils modifient en clientelle.

Dans ce cas, je fais (pas forcément de lien réseau):

- 1 backup de la bbd de production
- puis 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec Pc Anywhere).
Le portable a donc une base locale identique à celle de
production et est autonome.

Pour synchroniser les modifications de la base locale du
portable et de la base de production du serveur,
je fais à partir de la base de production du serveur :

- lecture via le réseau des données locales du portable
modifiées <portable local>.<bdd locale>.dbo.tables
et intégration dans la base de production du serveur, si
le portable est relié au réseau
- backup de la base locale du portable et restore sur une
base secondaire du serveur (via le réseau ou le
téléphone avec Pc Anywhere) si le portable n'est pas
relié au réseau, puis intégration des données
modifiées de cette base secondaire dans la base de
production du serveur

La base de production du serveur contient donc les données
modifiées sur le portable, mais le portable
n'a pas les données qui ont été modifiées sur le serveur
par ses collègues. Donc, à nouveau :

- 1 backup de la bbd de production du serveur
- 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec
Pc Anywhere).
Le portable a donc maintenant une base locale identique à
celle de production

NB : instructions utilisées, via le réseau :
backup database [base esf] to disk = 'c:efbase esf'
with init, skip
restore database [base esf] from disk = 'c:efbase
esf'

Cette synchronisation fonctionne mais a les contraintes
suivantes :

- fastidieuse et lourde
- manipulations à faire sur les deux postes (backup sur
l'un, restore sur l'autre si liaison par
PC Anywhere)
- lors d'un restore, l'utilisateur de connexion à la bdd
reste mais n'est plus relié à la bdd restaurée.
Il faut le supprimer et le recréer.

Je suis sûr qu'il y a une façon plus simple de
synchroniser 2 bdd distantes, sans passer par des backup,
des restore ou des Bulk copy (descente et remontage des
données de tables via des fichiers texte) :

- copier directement les fichiers data et log d'une bdd
distance sur le serveur, et inversement (les
fichiers refusent d'être copié) ?
- puis, les lier à une bdd secondaire sur le serveur ?
- puis, intégrer les modifications de cette base
secondaire dans la base de production du serveur ?
- puis, écraser les fichiers data et log de la bdd
distance par les nouveaux fichiers de la bdd de
production synchronisée (les fichiers refusent d'être
écrasé) ?


Merci d'avance de m'aider sur ce sujet épineux.

Mr Gautier Vincent
Tél : 02 97 63 91 90

Avatar
Patrice
SQL Server dispose aussi de possibilités de réplication. Peut-être à
examiner dans la doc en ligne ?

Cela pourrait sans doute être géré également au niveau applicatif...

Patrice

--

"Gautier Vincent" a écrit dans le
message de news:0bf201c4a174$fcb07ec0$
Amis de Newsgroup, experts en Sql Server, bonjour.

J'ai besoin de vos lumières sur la synchronisation de bdd
Sql server 2000 (V8) distantes.

C'est un peu long, mais explique bien ma situation...

J'ai un serveur Windows 2000 server, qui contient la bdd
de production Sql Server.
Plusieurs clients (portables et postes fixes) attaquent
cette base simultanément via un frontal Delphi, une
connexion ODBC et un lan TCP/IP.
OK pour cela.

Mon problème est quand les portables travaillent sur leur
bdd locale (identique à celle de production),
mais avec des données qu'ils modifient en clientelle.

Dans ce cas, je fais (pas forcément de lien réseau):

- 1 backup de la bbd de production
- puis 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec Pc Anywhere).
Le portable a donc une base locale identique à celle de
production et est autonome.

Pour synchroniser les modifications de la base locale du
portable et de la base de production du serveur,
je fais à partir de la base de production du serveur :

- lecture via le réseau des données locales du portable
modifiées <portable local>.<bdd locale>.dbo.tables
et intégration dans la base de production du serveur, si
le portable est relié au réseau
- backup de la base locale du portable et restore sur une
base secondaire du serveur (via le réseau ou le
téléphone avec Pc Anywhere) si le portable n'est pas
relié au réseau, puis intégration des données
modifiées de cette base secondaire dans la base de
production du serveur

La base de production du serveur contient donc les données
modifiées sur le portable, mais le portable
n'a pas les données qui ont été modifiées sur le serveur
par ses collègues. Donc, à nouveau :

- 1 backup de la bbd de production du serveur
- 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec
Pc Anywhere).
Le portable a donc maintenant une base locale identique à
celle de production

NB : instructions utilisées, via le réseau :
backup database [base esf] to disk = 'c:efbase esf'
with init, skip
restore database [base esf] from disk = 'c:efbase
esf'

Cette synchronisation fonctionne mais a les contraintes
suivantes :

- fastidieuse et lourde
- manipulations à faire sur les deux postes (backup sur
l'un, restore sur l'autre si liaison par
PC Anywhere)
- lors d'un restore, l'utilisateur de connexion à la bdd
reste mais n'est plus relié à la bdd restaurée.
Il faut le supprimer et le recréer.

Je suis sûr qu'il y a une façon plus simple de
synchroniser 2 bdd distantes, sans passer par des backup,
des restore ou des Bulk copy (descente et remontage des
données de tables via des fichiers texte) :

- copier directement les fichiers data et log d'une bdd
distance sur le serveur, et inversement (les
fichiers refusent d'être copié) ?
- puis, les lier à une bdd secondaire sur le serveur ?
- puis, intégrer les modifications de cette base
secondaire dans la base de production du serveur ?
- puis, écraser les fichiers data et log de la bdd
distance par les nouveaux fichiers de la bdd de
production synchronisée (les fichiers refusent d'être
écrasé) ?


Merci d'avance de m'aider sur ce sujet épineux.

Mr Gautier Vincent
Tél : 02 97 63 91 90

Avatar
Gautier vincent
Merci de te préoccuper de mon problème.

Il y a 20 tables modifiables par l'utilisateur itinérant.
-----Message d'origine-----
combien de table sont mise a jour par l'utilisateur


itinerant ?

"Gautier Vincent" a


écrit dans le
message de news: 0bf201c4a174$fcb07ec0$
Amis de Newsgroup, experts en Sql Server, bonjour.

J'ai besoin de vos lumières sur la synchronisation de bdd
Sql server 2000 (V8) distantes.

C'est un peu long, mais explique bien ma situation...

J'ai un serveur Windows 2000 server, qui contient la bdd
de production Sql Server.
Plusieurs clients (portables et postes fixes) attaquent
cette base simultanément via un frontal Delphi, une
connexion ODBC et un lan TCP/IP.
OK pour cela.

Mon problème est quand les portables travaillent sur leur
bdd locale (identique à celle de production),
mais avec des données qu'ils modifient en clientelle.

Dans ce cas, je fais (pas forcément de lien réseau):

- 1 backup de la bbd de production
- puis 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec Pc Anywhere).
Le portable a donc une base locale identique à celle de
production et est autonome.

Pour synchroniser les modifications de la base locale du
portable et de la base de production du serveur,
je fais à partir de la base de production du serveur :

- lecture via le réseau des données locales du portable
modifiées <portable local>.<bdd locale>.dbo.tables
et intégration dans la base de production du serveur, si
le portable est relié au réseau
- backup de la base locale du portable et restore sur une
base secondaire du serveur (via le réseau ou le
téléphone avec Pc Anywhere) si le portable n'est pas
relié au réseau, puis intégration des données
modifiées de cette base secondaire dans la base de
production du serveur

La base de production du serveur contient donc les données
modifiées sur le portable, mais le portable
n'a pas les données qui ont été modifiées sur le serveur
par ses collègues. Donc, à nouveau :

- 1 backup de la bbd de production du serveur
- 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec
Pc Anywhere).
Le portable a donc maintenant une base locale identique à
celle de production

NB : instructions utilisées, via le réseau :
backup database [base esf] to disk = 'c:efbase esf'
with init, skip
restore database [base esf] from disk = 'c:efbase
esf'

Cette synchronisation fonctionne mais a les contraintes
suivantes :

- fastidieuse et lourde
- manipulations à faire sur les deux postes (backup sur
l'un, restore sur l'autre si liaison par
PC Anywhere)
- lors d'un restore, l'utilisateur de connexion à la bdd
reste mais n'est plus relié à la bdd restaurée.
Il faut le supprimer et le recréer.

Je suis sûr qu'il y a une façon plus simple de
synchroniser 2 bdd distantes, sans passer par des backup,
des restore ou des Bulk copy (descente et remontage des
données de tables via des fichiers texte) :

- copier directement les fichiers data et log d'une bdd
distance sur le serveur, et inversement (les
fichiers refusent d'être copié) ?
- puis, les lier à une bdd secondaire sur le serveur ?
- puis, intégrer les modifications de cette base
secondaire dans la base de production du serveur ?
- puis, écraser les fichiers data et log de la bdd
distance par les nouveaux fichiers de la bdd de
production synchronisée (les fichiers refusent d'être
écrasé) ?


Merci d'avance de m'aider sur ce sujet épineux.

Mr Gautier Vincent
Tél : 02 97 63 91 90



.



Avatar
AXL
nous avons eu le meme probleme avec notre application commerciale!!

Nous pour eviter ce probleme lorsque le commerciale crée ou modifie des
informations, nous avons ajouter un flag sur la table et nous transferons
que les informations flager.
par exemple : lorsque le commercial modifie un client le champ de flag passe
de NULL a MOD et lorsque qu'il en creé un il passe a NEW.

ensuite via le serveur lié on transfere que les infos de type NEW et MOD
avec les traitements qui sont lié.

Pour la recupération, le probleme est lié a la ligne, le backup restore pose
un probleme quand c du rtc car il y a vraiment un probleme de lenteur et de
stabilité.
Je me suis appercu que pour le rtc en passant par des requete en serveur lié
on est plus rapide que par le backup restore donc je vide la base et je
recupere tout.
On arrive a des temps acceptable 1 heure sur du rtc sur une base de données
de 500 Mo et 20 Minutes en reseau local (wifi 11Mo crete).

voila ma solution, une parmis beaucoup d'autre. Le transfert par fichier
texte est tres bien car tres rapide au tranfert; mais nous avons abandonné
suite a des problemes d'integrités .

AXL


"Gautier vincent" a écrit dans le
message de news: 2d5f01c4a20c$70dd6000$
Merci de te préoccuper de mon problème.

Il y a 20 tables modifiables par l'utilisateur itinérant.
-----Message d'origine-----
combien de table sont mise a jour par l'utilisateur


itinerant ?

"Gautier Vincent" a


écrit dans le
message de news: 0bf201c4a174$fcb07ec0$
Amis de Newsgroup, experts en Sql Server, bonjour.

J'ai besoin de vos lumières sur la synchronisation de bdd
Sql server 2000 (V8) distantes.

C'est un peu long, mais explique bien ma situation...

J'ai un serveur Windows 2000 server, qui contient la bdd
de production Sql Server.
Plusieurs clients (portables et postes fixes) attaquent
cette base simultanément via un frontal Delphi, une
connexion ODBC et un lan TCP/IP.
OK pour cela.

Mon problème est quand les portables travaillent sur leur
bdd locale (identique à celle de production),
mais avec des données qu'ils modifient en clientelle.

Dans ce cas, je fais (pas forcément de lien réseau):

- 1 backup de la bbd de production
- puis 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec Pc Anywhere).
Le portable a donc une base locale identique à celle de
production et est autonome.

Pour synchroniser les modifications de la base locale du
portable et de la base de production du serveur,
je fais à partir de la base de production du serveur :

- lecture via le réseau des données locales du portable
modifiées <portable local>.<bdd locale>.dbo.tables
et intégration dans la base de production du serveur, si
le portable est relié au réseau
- backup de la base locale du portable et restore sur une
base secondaire du serveur (via le réseau ou le
téléphone avec Pc Anywhere) si le portable n'est pas
relié au réseau, puis intégration des données
modifiées de cette base secondaire dans la base de
production du serveur

La base de production du serveur contient donc les données
modifiées sur le portable, mais le portable
n'a pas les données qui ont été modifiées sur le serveur
par ses collègues. Donc, à nouveau :

- 1 backup de la bbd de production du serveur
- 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec
Pc Anywhere).
Le portable a donc maintenant une base locale identique à
celle de production

NB : instructions utilisées, via le réseau :
backup database [base esf] to disk = 'c:efbase esf'
with init, skip
restore database [base esf] from disk = 'c:efbase
esf'

Cette synchronisation fonctionne mais a les contraintes
suivantes :

- fastidieuse et lourde
- manipulations à faire sur les deux postes (backup sur
l'un, restore sur l'autre si liaison par
PC Anywhere)
- lors d'un restore, l'utilisateur de connexion à la bdd
reste mais n'est plus relié à la bdd restaurée.
Il faut le supprimer et le recréer.

Je suis sûr qu'il y a une façon plus simple de
synchroniser 2 bdd distantes, sans passer par des backup,
des restore ou des Bulk copy (descente et remontage des
données de tables via des fichiers texte) :

- copier directement les fichiers data et log d'une bdd
distance sur le serveur, et inversement (les
fichiers refusent d'être copié) ?
- puis, les lier à une bdd secondaire sur le serveur ?
- puis, intégrer les modifications de cette base
secondaire dans la base de production du serveur ?
- puis, écraser les fichiers data et log de la bdd
distance par les nouveaux fichiers de la bdd de
production synchronisée (les fichiers refusent d'être
écrasé) ?


Merci d'avance de m'aider sur ce sujet épineux.

Mr Gautier Vincent
Tél : 02 97 63 91 90



.



Avatar
AXL, Merci pour vos infos.

J'utilise également un flag de modification des données.

Qu'appellez-vous 'requêtes en serveur lié' ?

A ma connaissance, par le rtc (Pc anywhere ou ftp), on
transfert seulement des fichiers d'une façon automatique
(sans manipulation humaine sur le poste à distance). On ne
peut pas effectuer des requêtes sur une bdd distante sans
prendre la main sur le poste, et donc faire manuellement
des manipulations ?

Effacer une bdd (delete ...) et la remplir via le LAN
(Insert Select ...), OK, mais à distance via le rtc, en
automatique ?

Notre but idéal est le suivant (ce que font très bien les
Palm Pilot):
- Après sa journée, 1 commercial relie chez lui son
portable au téléphone, lance l'application de gestion
commerciale et appuie simplement sur 'Synchoniser'. Au
message 'Synchronisation terminée', Il éteint son portable.
Son portable est à jour et le serveur à distance aussi.

Je sais faire une sauvegarde (backup ou bcp) et lancer
PcAnywhere sur un poste distant dans une procédure
automatisée pour tranférer cette sauvegarde.
Mais pour que le serveur d'une manière automatique, en
recevant cette sauvegarde puisse la traiter, faire la
synchro, faire une nouvelle sauvegarde des données
synchronisées, la renvoyer au portable par PcAnywhere en
écrasant les données initiales du portable, JE NE SAIS PAS
FAIRE !

Une solution est d'établir une liaison internet sécurisée
VPN qui voit dans le LAN un poste distant, et permet donc
de faire des requêtes directes sur sa bdd, ou de le faire
travailler en direct sur la bdd de production.
LE PB, c'est le coût mensuel de cette liaison avec débit
correct et garanti (>500,00 ?/mois).
Le RTC est peu chère !

Avant d'utiliser Sql Server 2000, on utilisait Paradox V7,
et cette procédure fonctionnait, puisse Paradox est
composé de fichiers table.db qu'on peut copier et écraser
en local ou à distance sans problème.
Ce qui n'est plus le cas de Sql Server qui protège en
copie et écrasement ces fichiers sources (.mdf et . ldf),
ce qui oblige, à ma connaissance, de passer par des backup
ou bcp.

Merci de m'éclairer sur ce point, qui je pense intéresse
beaucoup de gens.

Cordialement.

Mr Gautier Vincent
tél : 02 97 63 91 90

-----Message d'origine-----
nous avons eu le meme probleme avec notre application


commerciale!!

Nous pour eviter ce probleme lorsque le commerciale crée


ou modifie des
informations, nous avons ajouter un flag sur la table et


nous transferons
que les informations flager.
par exemple : lorsque le commercial modifie un client le


champ de flag passe
de NULL a MOD et lorsque qu'il en creé un il passe a NEW.

ensuite via le serveur lié on transfere que les infos de


type NEW et MOD
avec les traitements qui sont lié.

Pour la recupération, le probleme est lié a la ligne, le


backup restore pose
un probleme quand c du rtc car il y a vraiment un


probleme de lenteur et de
stabilité.
Je me suis appercu que pour le rtc en passant par des


requete en serveur lié
on est plus rapide que par le backup restore donc je vide


la base et je
recupere tout.
On arrive a des temps acceptable 1 heure sur du rtc sur


une base de données
de 500 Mo et 20 Minutes en reseau local (wifi 11Mo crete).

voila ma solution, une parmis beaucoup d'autre. Le


transfert par fichier
texte est tres bien car tres rapide au tranfert; mais


nous avons abandonné
suite a des problemes d'integrités .

AXL


"Gautier vincent" a


écrit dans le
message de news: 2d5f01c4a20c$70dd6000$
Merci de te préoccuper de mon problème.

Il y a 20 tables modifiables par l'utilisateur itinérant.
-----Message d'origine-----
combien de table sont mise a jour par l'utilisateur


itinerant ?

"Gautier Vincent" a


écrit dans le
message de news: 0bf201c4a174$fcb07ec0




$
Amis de Newsgroup, experts en Sql Server, bonjour.

J'ai besoin de vos lumières sur la synchronisation de bdd
Sql server 2000 (V8) distantes.

C'est un peu long, mais explique bien ma situation...

J'ai un serveur Windows 2000 server, qui contient la bdd
de production Sql Server.
Plusieurs clients (portables et postes fixes) attaquent
cette base simultanément via un frontal Delphi, une
connexion ODBC et un lan TCP/IP.
OK pour cela.

Mon problème est quand les portables travaillent sur leur
bdd locale (identique à celle de production),
mais avec des données qu'ils modifient en clientelle.

Dans ce cas, je fais (pas forcément de lien réseau):

- 1 backup de la bbd de production
- puis 1 restore de cette sauvegarde sur la base locale




du
portable (via le réseau ou le téléphone avec Pc




Anywhere).
Le portable a donc une base locale identique à celle de
production et est autonome.

Pour synchroniser les modifications de la base locale du
portable et de la base de production du serveur,
je fais à partir de la base de production du serveur :

- lecture via le réseau des données locales du portable
modifiées <portable local>.<bdd locale>.dbo.tables
et intégration dans la base de production du serveur,




si
le portable est relié au réseau
- backup de la base locale du portable et restore sur une
base secondaire du serveur (via le réseau ou le
téléphone avec Pc Anywhere) si le portable n'est pas
relié au réseau, puis intégration des données
modifiées de cette base secondaire dans la base de
production du serveur

La base de production du serveur contient donc les




données
modifiées sur le portable, mais le portable
n'a pas les données qui ont été modifiées sur le serveur
par ses collègues. Donc, à nouveau :

- 1 backup de la bbd de production du serveur
- 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec
Pc Anywhere).
Le portable a donc maintenant une base locale identique à
celle de production

NB : instructions utilisées, via le réseau :
backup database [base esf] to disk = 'c:efbase




esf'
with init, skip
restore database [base esf] from disk = 'c:efbase
esf'

Cette synchronisation fonctionne mais a les contraintes
suivantes :

- fastidieuse et lourde
- manipulations à faire sur les deux postes (backup sur
l'un, restore sur l'autre si liaison par
PC Anywhere)
- lors d'un restore, l'utilisateur de connexion à la bdd
reste mais n'est plus relié à la bdd restaurée.
Il faut le supprimer et le recréer.

Je suis sûr qu'il y a une façon plus simple de
synchroniser 2 bdd distantes, sans passer par des backup,
des restore ou des Bulk copy (descente et remontage des
données de tables via des fichiers texte) :

- copier directement les fichiers data et log d'une bdd
distance sur le serveur, et inversement (les
fichiers refusent d'être copié) ?
- puis, les lier à une bdd secondaire sur le serveur ?
- puis, intégrer les modifications de cette base
secondaire dans la base de production du serveur ?
- puis, écraser les fichiers data et log de la bdd
distance par les nouveaux fichiers de la bdd de
production synchronisée (les fichiers refusent d'être
écrasé) ?


Merci d'avance de m'aider sur ce sujet épineux.

Mr Gautier Vincent
Tél : 02 97 63 91 90



.





.



Avatar
Gautier Vincent
Merci pour ta réponse, Patrice.

J'ai bien étudié la réplication Sql Server 2000.

Dans notre cas, si j'ai bien compris, elle est
inutilisable, car les postes sur le LAN ou à distance (bdd
locale) peuvent modifier des données communes, avec une
renumérotation des clés temporaires (n° devis et facture)
en clés définitives après une synchronisation.

La réplication est faite pour des abonnés qui ont leurs
propres identifications et travaillent sur leurs propres
données.
La synchronisation ne fait qu'une fusion directe des
données, sans traitement particulier.


-----Message d'origine-----
SQL Server dispose aussi de possibilités de réplication.


Peut-être à
examiner dans la doc en ligne ?

Cela pourrait sans doute être géré également au niveau


applicatif...

Patrice

--

"Gautier Vincent" a


écrit dans le
message de news:0bf201c4a174$fcb07ec0$
Amis de Newsgroup, experts en Sql Server, bonjour.

J'ai besoin de vos lumières sur la synchronisation de bdd
Sql server 2000 (V8) distantes.

C'est un peu long, mais explique bien ma situation...

J'ai un serveur Windows 2000 server, qui contient la bdd
de production Sql Server.
Plusieurs clients (portables et postes fixes) attaquent
cette base simultanément via un frontal Delphi, une
connexion ODBC et un lan TCP/IP.
OK pour cela.

Mon problème est quand les portables travaillent sur leur
bdd locale (identique à celle de production),
mais avec des données qu'ils modifient en clientelle.

Dans ce cas, je fais (pas forcément de lien réseau):

- 1 backup de la bbd de production
- puis 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec Pc Anywhere).
Le portable a donc une base locale identique à celle de
production et est autonome.

Pour synchroniser les modifications de la base locale du
portable et de la base de production du serveur,
je fais à partir de la base de production du serveur :

- lecture via le réseau des données locales du portable
modifiées <portable local>.<bdd locale>.dbo.tables
et intégration dans la base de production du serveur, si
le portable est relié au réseau
- backup de la base locale du portable et restore sur une
base secondaire du serveur (via le réseau ou le
téléphone avec Pc Anywhere) si le portable n'est pas
relié au réseau, puis intégration des données
modifiées de cette base secondaire dans la base de
production du serveur

La base de production du serveur contient donc les données
modifiées sur le portable, mais le portable
n'a pas les données qui ont été modifiées sur le serveur
par ses collègues. Donc, à nouveau :

- 1 backup de la bbd de production du serveur
- 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec
Pc Anywhere).
Le portable a donc maintenant une base locale identique à
celle de production

NB : instructions utilisées, via le réseau :
backup database [base esf] to disk = 'c:efbase esf'
with init, skip
restore database [base esf] from disk = 'c:efbase
esf'

Cette synchronisation fonctionne mais a les contraintes
suivantes :

- fastidieuse et lourde
- manipulations à faire sur les deux postes (backup sur
l'un, restore sur l'autre si liaison par
PC Anywhere)
- lors d'un restore, l'utilisateur de connexion à la bdd
reste mais n'est plus relié à la bdd restaurée.
Il faut le supprimer et le recréer.

Je suis sûr qu'il y a une façon plus simple de
synchroniser 2 bdd distantes, sans passer par des backup,
des restore ou des Bulk copy (descente et remontage des
données de tables via des fichiers texte) :

- copier directement les fichiers data et log d'une bdd
distance sur le serveur, et inversement (les
fichiers refusent d'être copié) ?
- puis, les lier à une bdd secondaire sur le serveur ?
- puis, intégrer les modifications de cette base
secondaire dans la base de production du serveur ?
- puis, écraser les fichiers data et log de la bdd
distance par les nouveaux fichiers de la bdd de
production synchronisée (les fichiers refusent d'être
écrasé) ?


Merci d'avance de m'aider sur ce sujet épineux.

Mr Gautier Vincent
Tél : 02 97 63 91 90



.



Avatar
Gloup
Bonjour,

Pourquoi ne pas simplement créer une publication avec SQL Server? Le client
peut se synchroniser (même automatiquement) dès qu'il a une connexion
réseau. Pour avoir une idée de la config synchro client, il te suffit
d'aller dans "Démarrer / Programmes /accessoires / Synchroniser". Il y a la
ce qu'il faut pour créer une souscription.
Dans SQL Server, tu crées ta publication dans "Réplication / Publications".
Je ne l'ai jamais utilisé que pour faire des tests, mais cela avait l'air de
très bien fonctionner. Mais clairement, soit le client à une connexion VPN
pour se connecter et faire la synchro, soit ton SQL Server est accessible
via Internet.
Maintenant, je n'ai aucune idée des temps de synchro, mais j'imagine que ce
serait plus rapide que faire du transfert de backup.

J'espère t'avoir aidé.

Gloup ;o)

"Gautier Vincent" a écrit dans le
message de news: 0bf201c4a174$fcb07ec0$
Amis de Newsgroup, experts en Sql Server, bonjour.

J'ai besoin de vos lumières sur la synchronisation de bdd
Sql server 2000 (V8) distantes.

C'est un peu long, mais explique bien ma situation...

J'ai un serveur Windows 2000 server, qui contient la bdd
de production Sql Server.
Plusieurs clients (portables et postes fixes) attaquent
cette base simultanément via un frontal Delphi, une
connexion ODBC et un lan TCP/IP.
OK pour cela.

Mon problème est quand les portables travaillent sur leur
bdd locale (identique à celle de production),
mais avec des données qu'ils modifient en clientelle.

Dans ce cas, je fais (pas forcément de lien réseau):

- 1 backup de la bbd de production
- puis 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec Pc Anywhere).
Le portable a donc une base locale identique à celle de
production et est autonome.

Pour synchroniser les modifications de la base locale du
portable et de la base de production du serveur,
je fais à partir de la base de production du serveur :

- lecture via le réseau des données locales du portable
modifiées <portable local>.<bdd locale>.dbo.tables
et intégration dans la base de production du serveur, si
le portable est relié au réseau
- backup de la base locale du portable et restore sur une
base secondaire du serveur (via le réseau ou le
téléphone avec Pc Anywhere) si le portable n'est pas
relié au réseau, puis intégration des données
modifiées de cette base secondaire dans la base de
production du serveur

La base de production du serveur contient donc les données
modifiées sur le portable, mais le portable
n'a pas les données qui ont été modifiées sur le serveur
par ses collègues. Donc, à nouveau :

- 1 backup de la bbd de production du serveur
- 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec
Pc Anywhere).
Le portable a donc maintenant une base locale identique à
celle de production

NB : instructions utilisées, via le réseau :
backup database [base esf] to disk = 'c:efbase esf'
with init, skip
restore database [base esf] from disk = 'c:efbase
esf'

Cette synchronisation fonctionne mais a les contraintes
suivantes :

- fastidieuse et lourde
- manipulations à faire sur les deux postes (backup sur
l'un, restore sur l'autre si liaison par
PC Anywhere)
- lors d'un restore, l'utilisateur de connexion à la bdd
reste mais n'est plus relié à la bdd restaurée.
Il faut le supprimer et le recréer.

Je suis sûr qu'il y a une façon plus simple de
synchroniser 2 bdd distantes, sans passer par des backup,
des restore ou des Bulk copy (descente et remontage des
données de tables via des fichiers texte) :

- copier directement les fichiers data et log d'une bdd
distance sur le serveur, et inversement (les
fichiers refusent d'être copié) ?
- puis, les lier à une bdd secondaire sur le serveur ?
- puis, intégrer les modifications de cette base
secondaire dans la base de production du serveur ?
- puis, écraser les fichiers data et log de la bdd
distance par les nouveaux fichiers de la bdd de
production synchronisée (les fichiers refusent d'être
écrasé) ?


Merci d'avance de m'aider sur ce sujet épineux.

Mr Gautier Vincent
Tél : 02 97 63 91 90

Avatar
AXL
Salut,

un serveur lié comme son nom l'indique permet de creer une connection
approuvé entre deux serveur comme si il ne faisait qu'un!!

je m'explique :

tu as un serveur A et un Serveur B , c deux serveurs ont des bases
differentes mais on a besoin d'accede sur le serveur B a certaine données du
serveur A en temps reel.

donc tu cree un serveur lie sur B de A ce qui peux te permettre en etant
connecter sur le serveur B de faire des operations sur le serveur A.

select * from B.mabase.dbo.matable where monchamp=montest


POur ton application c simple tu cree une application qui ouvre un reseau
distant via rtc ou pigeon voyageur (moins simple) et ensuite tu transfert
tes données.



a écrit dans le message de news:
355101c4a475$39add900$
AXL, Merci pour vos infos.

J'utilise également un flag de modification des données.

Qu'appellez-vous 'requêtes en serveur lié' ?

A ma connaissance, par le rtc (Pc anywhere ou ftp), on
transfert seulement des fichiers d'une façon automatique
(sans manipulation humaine sur le poste à distance). On ne
peut pas effectuer des requêtes sur une bdd distante sans
prendre la main sur le poste, et donc faire manuellement
des manipulations ?

Effacer une bdd (delete ...) et la remplir via le LAN
(Insert Select ...), OK, mais à distance via le rtc, en
automatique ?

Notre but idéal est le suivant (ce que font très bien les
Palm Pilot):
- Après sa journée, 1 commercial relie chez lui son
portable au téléphone, lance l'application de gestion
commerciale et appuie simplement sur 'Synchoniser'. Au
message 'Synchronisation terminée', Il éteint son portable.
Son portable est à jour et le serveur à distance aussi.

Je sais faire une sauvegarde (backup ou bcp) et lancer
PcAnywhere sur un poste distant dans une procédure
automatisée pour tranférer cette sauvegarde.
Mais pour que le serveur d'une manière automatique, en
recevant cette sauvegarde puisse la traiter, faire la
synchro, faire une nouvelle sauvegarde des données
synchronisées, la renvoyer au portable par PcAnywhere en
écrasant les données initiales du portable, JE NE SAIS PAS
FAIRE !

Une solution est d'établir une liaison internet sécurisée
VPN qui voit dans le LAN un poste distant, et permet donc
de faire des requêtes directes sur sa bdd, ou de le faire
travailler en direct sur la bdd de production.
LE PB, c'est le coût mensuel de cette liaison avec débit
correct et garanti (>500,00 ?/mois).
Le RTC est peu chère !

Avant d'utiliser Sql Server 2000, on utilisait Paradox V7,
et cette procédure fonctionnait, puisse Paradox est
composé de fichiers table.db qu'on peut copier et écraser
en local ou à distance sans problème.
Ce qui n'est plus le cas de Sql Server qui protège en
copie et écrasement ces fichiers sources (.mdf et . ldf),
ce qui oblige, à ma connaissance, de passer par des backup
ou bcp.

Merci de m'éclairer sur ce point, qui je pense intéresse
beaucoup de gens.

Cordialement.

Mr Gautier Vincent
tél : 02 97 63 91 90

-----Message d'origine-----
nous avons eu le meme probleme avec notre application


commerciale!!

Nous pour eviter ce probleme lorsque le commerciale crée


ou modifie des
informations, nous avons ajouter un flag sur la table et


nous transferons
que les informations flager.
par exemple : lorsque le commercial modifie un client le


champ de flag passe
de NULL a MOD et lorsque qu'il en creé un il passe a NEW.

ensuite via le serveur lié on transfere que les infos de


type NEW et MOD
avec les traitements qui sont lié.

Pour la recupération, le probleme est lié a la ligne, le


backup restore pose
un probleme quand c du rtc car il y a vraiment un


probleme de lenteur et de
stabilité.
Je me suis appercu que pour le rtc en passant par des


requete en serveur lié
on est plus rapide que par le backup restore donc je vide


la base et je
recupere tout.
On arrive a des temps acceptable 1 heure sur du rtc sur


une base de données
de 500 Mo et 20 Minutes en reseau local (wifi 11Mo crete).

voila ma solution, une parmis beaucoup d'autre. Le


transfert par fichier
texte est tres bien car tres rapide au tranfert; mais


nous avons abandonné
suite a des problemes d'integrités .

AXL


"Gautier vincent" a


écrit dans le
message de news: 2d5f01c4a20c$70dd6000$
Merci de te préoccuper de mon problème.

Il y a 20 tables modifiables par l'utilisateur itinérant.
-----Message d'origine-----
combien de table sont mise a jour par l'utilisateur


itinerant ?

"Gautier Vincent" a


écrit dans le
message de news: 0bf201c4a174$fcb07ec0




$
Amis de Newsgroup, experts en Sql Server, bonjour.

J'ai besoin de vos lumières sur la synchronisation de bdd
Sql server 2000 (V8) distantes.

C'est un peu long, mais explique bien ma situation...

J'ai un serveur Windows 2000 server, qui contient la bdd
de production Sql Server.
Plusieurs clients (portables et postes fixes) attaquent
cette base simultanément via un frontal Delphi, une
connexion ODBC et un lan TCP/IP.
OK pour cela.

Mon problème est quand les portables travaillent sur leur
bdd locale (identique à celle de production),
mais avec des données qu'ils modifient en clientelle.

Dans ce cas, je fais (pas forcément de lien réseau):

- 1 backup de la bbd de production
- puis 1 restore de cette sauvegarde sur la base locale




du
portable (via le réseau ou le téléphone avec Pc




Anywhere).
Le portable a donc une base locale identique à celle de
production et est autonome.

Pour synchroniser les modifications de la base locale du
portable et de la base de production du serveur,
je fais à partir de la base de production du serveur :

- lecture via le réseau des données locales du portable
modifiées <portable local>.<bdd locale>.dbo.tables
et intégration dans la base de production du serveur,




si
le portable est relié au réseau
- backup de la base locale du portable et restore sur une
base secondaire du serveur (via le réseau ou le
téléphone avec Pc Anywhere) si le portable n'est pas
relié au réseau, puis intégration des données
modifiées de cette base secondaire dans la base de
production du serveur

La base de production du serveur contient donc les




données
modifiées sur le portable, mais le portable
n'a pas les données qui ont été modifiées sur le serveur
par ses collègues. Donc, à nouveau :

- 1 backup de la bbd de production du serveur
- 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec
Pc Anywhere).
Le portable a donc maintenant une base locale identique à
celle de production

NB : instructions utilisées, via le réseau :
backup database [base esf] to disk = 'c:efbase




esf'
with init, skip
restore database [base esf] from disk = 'c:efbase
esf'

Cette synchronisation fonctionne mais a les contraintes
suivantes :

- fastidieuse et lourde
- manipulations à faire sur les deux postes (backup sur
l'un, restore sur l'autre si liaison par
PC Anywhere)
- lors d'un restore, l'utilisateur de connexion à la bdd
reste mais n'est plus relié à la bdd restaurée.
Il faut le supprimer et le recréer.

Je suis sûr qu'il y a une façon plus simple de
synchroniser 2 bdd distantes, sans passer par des backup,
des restore ou des Bulk copy (descente et remontage des
données de tables via des fichiers texte) :

- copier directement les fichiers data et log d'une bdd
distance sur le serveur, et inversement (les
fichiers refusent d'être copié) ?
- puis, les lier à une bdd secondaire sur le serveur ?
- puis, intégrer les modifications de cette base
secondaire dans la base de production du serveur ?
- puis, écraser les fichiers data et log de la bdd
distance par les nouveaux fichiers de la bdd de
production synchronisée (les fichiers refusent d'être
écrasé) ?


Merci d'avance de m'aider sur ce sujet épineux.

Mr Gautier Vincent
Tél : 02 97 63 91 90



.





.



Avatar
Salut AXL,

ça m'aiderais que tu m'envoies des infos sur la création
d'un serveur lié, qui peut en effet m'intéréssé si son
utilisation évite de faire des manipulations humaines sur
ce poste distant.

Merci et a +

Mr Gautier Vincent
tél : 02 97 63 91 90

-----Message d'origine-----
Salut,

un serveur lié comme son nom l'indique permet de creer


une connection
approuvé entre deux serveur comme si il ne faisait qu'un!!

je m'explique :

tu as un serveur A et un Serveur B , c deux serveurs ont


des bases
differentes mais on a besoin d'accede sur le serveur B a


certaine données du
serveur A en temps reel.

donc tu cree un serveur lie sur B de A ce qui peux te


permettre en etant
connecter sur le serveur B de faire des operations sur le


serveur A.

select * from B.mabase.dbo.matable where monchamp=montest


POur ton application c simple tu cree une application qui


ouvre un reseau
distant via rtc ou pigeon voyageur (moins simple) et


ensuite tu transfert
tes données.



a écrit dans le


message de news:
355101c4a475$39add900$
AXL, Merci pour vos infos.

J'utilise également un flag de modification des données.

Qu'appellez-vous 'requêtes en serveur lié' ?

A ma connaissance, par le rtc (Pc anywhere ou ftp), on
transfert seulement des fichiers d'une façon automatique
(sans manipulation humaine sur le poste à distance). On ne
peut pas effectuer des requêtes sur une bdd distante sans
prendre la main sur le poste, et donc faire manuellement
des manipulations ?

Effacer une bdd (delete ...) et la remplir via le LAN
(Insert Select ...), OK, mais à distance via le rtc, en
automatique ?

Notre but idéal est le suivant (ce que font très bien les
Palm Pilot):
- Après sa journée, 1 commercial relie chez lui son
portable au téléphone, lance l'application de gestion
commerciale et appuie simplement sur 'Synchoniser'. Au
message 'Synchronisation terminée', Il éteint son


portable.
Son portable est à jour et le serveur à distance aussi.

Je sais faire une sauvegarde (backup ou bcp) et lancer
PcAnywhere sur un poste distant dans une procédure
automatisée pour tranférer cette sauvegarde.
Mais pour que le serveur d'une manière automatique, en
recevant cette sauvegarde puisse la traiter, faire la
synchro, faire une nouvelle sauvegarde des données
synchronisées, la renvoyer au portable par PcAnywhere en
écrasant les données initiales du portable, JE NE SAIS PAS
FAIRE !

Une solution est d'établir une liaison internet sécurisée
VPN qui voit dans le LAN un poste distant, et permet donc
de faire des requêtes directes sur sa bdd, ou de le faire
travailler en direct sur la bdd de production.
LE PB, c'est le coût mensuel de cette liaison avec débit
correct et garanti (>500,00 ?/mois).
Le RTC est peu chère !

Avant d'utiliser Sql Server 2000, on utilisait Paradox V7,
et cette procédure fonctionnait, puisse Paradox est
composé de fichiers table.db qu'on peut copier et écraser
en local ou à distance sans problème.
Ce qui n'est plus le cas de Sql Server qui protège en
copie et écrasement ces fichiers sources (.mdf et . ldf),
ce qui oblige, à ma connaissance, de passer par des backup
ou bcp.

Merci de m'éclairer sur ce point, qui je pense intéresse
beaucoup de gens.

Cordialement.

Mr Gautier Vincent
tél : 02 97 63 91 90

-----Message d'origine-----
nous avons eu le meme probleme avec notre application


commerciale!!

Nous pour eviter ce probleme lorsque le commerciale crée


ou modifie des
informations, nous avons ajouter un flag sur la table et


nous transferons
que les informations flager.
par exemple : lorsque le commercial modifie un client le


champ de flag passe
de NULL a MOD et lorsque qu'il en creé un il passe a NEW.

ensuite via le serveur lié on transfere que les infos de


type NEW et MOD
avec les traitements qui sont lié.

Pour la recupération, le probleme est lié a la ligne, le


backup restore pose
un probleme quand c du rtc car il y a vraiment un


probleme de lenteur et de
stabilité.
Je me suis appercu que pour le rtc en passant par des


requete en serveur lié
on est plus rapide que par le backup restore donc je vide


la base et je
recupere tout.
On arrive a des temps acceptable 1 heure sur du rtc sur


une base de données
de 500 Mo et 20 Minutes en reseau local (wifi 11Mo




crete).

voila ma solution, une parmis beaucoup d'autre. Le


transfert par fichier
texte est tres bien car tres rapide au tranfert; mais


nous avons abandonné
suite a des problemes d'integrités .

AXL


"Gautier vincent" a


écrit dans le
message de news: 2d5f01c4a20c$70dd6000




$
Merci de te préoccuper de mon problème.

Il y a 20 tables modifiables par l'utilisateur itinérant.
-----Message d'origine-----
combien de table sont mise a jour par l'utilisateur


itinerant ?

"Gautier Vincent"






a
écrit dans le
message de news: 0bf201c4a174$fcb07ec0




$
Amis de Newsgroup, experts en Sql Server, bonjour.

J'ai besoin de vos lumières sur la synchronisation de






bdd
Sql server 2000 (V8) distantes.

C'est un peu long, mais explique bien ma situation...

J'ai un serveur Windows 2000 server, qui contient la bdd
de production Sql Server.
Plusieurs clients (portables et postes fixes) attaquent
cette base simultanément via un frontal Delphi, une
connexion ODBC et un lan TCP/IP.
OK pour cela.

Mon problème est quand les portables travaillent sur






leur
bdd locale (identique à celle de production),
mais avec des données qu'ils modifient en clientelle.

Dans ce cas, je fais (pas forcément de lien réseau):

- 1 backup de la bbd de production
- puis 1 restore de cette sauvegarde sur la base locale




du
portable (via le réseau ou le téléphone avec Pc




Anywhere).
Le portable a donc une base locale identique à celle de
production et est autonome.

Pour synchroniser les modifications de la base locale du
portable et de la base de production du serveur,
je fais à partir de la base de production du serveur :

- lecture via le réseau des données locales du portable
modifiées <portable local>.<bdd locale>.dbo.tables
et intégration dans la base de production du serveur,




si
le portable est relié au réseau
- backup de la base locale du portable et restore sur






une
base secondaire du serveur (via le réseau ou le
téléphone avec Pc Anywhere) si le portable n'est pas
relié au réseau, puis intégration des données
modifiées de cette base secondaire dans la base de
production du serveur

La base de production du serveur contient donc les




données
modifiées sur le portable, mais le portable
n'a pas les données qui ont été modifiées sur le serveur
par ses collègues. Donc, à nouveau :

- 1 backup de la bbd de production du serveur
- 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec
Pc Anywhere).
Le portable a donc maintenant une base locale identique






à
celle de production

NB : instructions utilisées, via le réseau :
backup database [base esf] to disk = 'c:efbase




esf'
with init, skip
restore database [base esf] from disk = 'c:efbase
esf'

Cette synchronisation fonctionne mais a les contraintes
suivantes :

- fastidieuse et lourde
- manipulations à faire sur les deux postes (backup sur
l'un, restore sur l'autre si liaison par
PC Anywhere)
- lors d'un restore, l'utilisateur de connexion à la bdd
reste mais n'est plus relié à la bdd restaurée.
Il faut le supprimer et le recréer.

Je suis sûr qu'il y a une façon plus simple de
synchroniser 2 bdd distantes, sans passer par des






backup,
des restore ou des Bulk copy (descente et remontage des
données de tables via des fichiers texte) :

- copier directement les fichiers data et log d'une bdd
distance sur le serveur, et inversement (les
fichiers refusent d'être copié) ?
- puis, les lier à une bdd secondaire sur le serveur ?
- puis, intégrer les modifications de cette base
secondaire dans la base de production du serveur ?
- puis, écraser les fichiers data et log de la bdd
distance par les nouveaux fichiers de la bdd de
production synchronisée (les fichiers refusent d'être
écrasé) ?


Merci d'avance de m'aider sur ce sujet épineux.

Mr Gautier Vincent
Tél : 02 97 63 91 90



.





.





.



Avatar
bruno reiter [MVP]
La réplication est exactement faite pour ce type d'application, il faut
"simplement" ;-) le prévoir à la conception.

br

"Gautier Vincent" wrote in message
news:299601c4a476$f0ae0890$
Merci pour ta réponse, Patrice.

J'ai bien étudié la réplication Sql Server 2000.

Dans notre cas, si j'ai bien compris, elle est
inutilisable, car les postes sur le LAN ou à distance (bdd
locale) peuvent modifier des données communes, avec une
renumérotation des clés temporaires (n° devis et facture)
en clés définitives après une synchronisation.

La réplication est faite pour des abonnés qui ont leurs
propres identifications et travaillent sur leurs propres
données.
La synchronisation ne fait qu'une fusion directe des
données, sans traitement particulier.


-----Message d'origine-----
SQL Server dispose aussi de possibilités de réplication.


Peut-être à
examiner dans la doc en ligne ?

Cela pourrait sans doute être géré également au niveau


applicatif...

Patrice

--

"Gautier Vincent" a


écrit dans le
message de news:0bf201c4a174$fcb07ec0$
Amis de Newsgroup, experts en Sql Server, bonjour.

J'ai besoin de vos lumières sur la synchronisation de bdd
Sql server 2000 (V8) distantes.

C'est un peu long, mais explique bien ma situation...

J'ai un serveur Windows 2000 server, qui contient la bdd
de production Sql Server.
Plusieurs clients (portables et postes fixes) attaquent
cette base simultanément via un frontal Delphi, une
connexion ODBC et un lan TCP/IP.
OK pour cela.

Mon problème est quand les portables travaillent sur leur
bdd locale (identique à celle de production),
mais avec des données qu'ils modifient en clientelle.

Dans ce cas, je fais (pas forcément de lien réseau):

- 1 backup de la bbd de production
- puis 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec Pc Anywhere).
Le portable a donc une base locale identique à celle de
production et est autonome.

Pour synchroniser les modifications de la base locale du
portable et de la base de production du serveur,
je fais à partir de la base de production du serveur :

- lecture via le réseau des données locales du portable
modifiées <portable local>.<bdd locale>.dbo.tables
et intégration dans la base de production du serveur, si
le portable est relié au réseau
- backup de la base locale du portable et restore sur une
base secondaire du serveur (via le réseau ou le
téléphone avec Pc Anywhere) si le portable n'est pas
relié au réseau, puis intégration des données
modifiées de cette base secondaire dans la base de
production du serveur

La base de production du serveur contient donc les données
modifiées sur le portable, mais le portable
n'a pas les données qui ont été modifiées sur le serveur
par ses collègues. Donc, à nouveau :

- 1 backup de la bbd de production du serveur
- 1 restore de cette sauvegarde sur la base locale du
portable (via le réseau ou le téléphone avec
Pc Anywhere).
Le portable a donc maintenant une base locale identique à
celle de production

NB : instructions utilisées, via le réseau :
backup database [base esf] to disk = 'c:efbase esf'
with init, skip
restore database [base esf] from disk = 'c:efbase
esf'

Cette synchronisation fonctionne mais a les contraintes
suivantes :

- fastidieuse et lourde
- manipulations à faire sur les deux postes (backup sur
l'un, restore sur l'autre si liaison par
PC Anywhere)
- lors d'un restore, l'utilisateur de connexion à la bdd
reste mais n'est plus relié à la bdd restaurée.
Il faut le supprimer et le recréer.

Je suis sûr qu'il y a une façon plus simple de
synchroniser 2 bdd distantes, sans passer par des backup,
des restore ou des Bulk copy (descente et remontage des
données de tables via des fichiers texte) :

- copier directement les fichiers data et log d'une bdd
distance sur le serveur, et inversement (les
fichiers refusent d'être copié) ?
- puis, les lier à une bdd secondaire sur le serveur ?
- puis, intégrer les modifications de cette base
secondaire dans la base de production du serveur ?
- puis, écraser les fichiers data et log de la bdd
distance par les nouveaux fichiers de la bdd de
production synchronisée (les fichiers refusent d'être
écrasé) ?


Merci d'avance de m'aider sur ce sujet épineux.

Mr Gautier Vincent
Tél : 02 97 63 91 90



.



1 2