Sql Server 2000 : synchronisation de bdd distantes

-----Message d'origine-----
La réplication est exactement faite pour ce type

"simplement" ;-) le prévoir à la conception.

br

"Gautier Vincent" <anonymous@discussions.microsoft.com>

news:299601c4a476$f0ae0890$a301280a@phx.gbl...
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" <anonymous@discussions.microsoft.com> a

écrit dans le

message de news:0bf201c4a174$fcb07ec0$a301280a@phx.gbl...
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

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

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,

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

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

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
technique@espacefermetures.com


.

.

-----Message d'origine-----
Bonjour,

Pourquoi ne pas simplement créer une publication avec SQL

peut se synchroniser (même automatiquement) dès qu'il a

réseau. Pour avoir une idée de la config synchro client,

d'aller dans "Démarrer / Programmes /accessoires /

ce qu'il faut pour créer une souscription.
Dans SQL Server, tu crées ta publication

Je ne l'ai jamais utilisé que pour faire des tests, mais

très bien fonctionner. Mais clairement, soit le client à

pour se connecter et faire la synchro, soit ton SQL

via Internet.
Maintenant, je n'ai aucune idée des temps de synchro,

serait plus rapide que faire du transfert de backup.

J'espère t'avoir aidé.

Gloup ;o)

"Gautier Vincent" <anonymous@discussions.microsoft.com> a

message de news: 0bf201c4a174$fcb07ec0$a301280a@phx.gbl...
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
technique@espacefermetures.com


.

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

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

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

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

serveur A en temps reel.

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

connecter sur le serveur B de faire des operations sur le

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


POur ton application c simple tu cree une application qui

distant via rtc ou pigeon voyageur (moins simple) et

tes données.



<anonymous@discussions.microsoft.com> a écrit dans le

355101c4a475$39add900$a401280a@phx.gbl...
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

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
technique@espacefermetures.com

-----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

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" <anonymous@discussions.microsoft.com> 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" <anonymous@discussions.microsoft.com>

écrit dans le

message de news: 0bf201c4a174$fcb07ec0

$a301280a@phx.gbl...

Amis de Newsgroup, experts en Sql Server, bonjour.

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

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

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

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

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
technique@espacefermetures.com


.

.

.

-----Message d'origine-----
La réplication est exactement faite pour ce type

"simplement" ;-) le prévoir à la conception.

br

"Gautier Vincent" <anonymous@discussions.microsoft.com>

news:299601c4a476$f0ae0890$a301280a@phx.gbl...
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" <anonymous@discussions.microsoft.com> a

écrit dans le

message de news:0bf201c4a174$fcb07ec0$a301280a@phx.gbl...
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

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

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,

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

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

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
technique@espacefermetures.com


.

.

-----Message d'origine-----
La réplication est exactement faite pour ce type

"simplement" ;-) le prévoir à la conception.

br

"Gautier Vincent" <anonymous@discussions.microsoft.com>

news:299601c4a476$f0ae0890$a301280a@phx.gbl...
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" <anonymous@discussions.microsoft.com> a

écrit dans le

message de news:0bf201c4a174$fcb07ec0$a301280a@phx.gbl...
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

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

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,

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

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

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
technique@espacefermetures.com


.

.

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

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

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

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

serveur A en temps reel.

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

connecter sur le serveur B de faire des operations sur le

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


POur ton application c simple tu cree une application qui

distant via rtc ou pigeon voyageur (moins simple) et

tes données.



<anonymous@discussions.microsoft.com> a écrit dans le

355101c4a475$39add900$a401280a@phx.gbl...
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

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
technique@espacefermetures.com

-----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

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" <anonymous@discussions.microsoft.com> 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" <anonymous@discussions.microsoft.com>

écrit dans le

message de news: 0bf201c4a174$fcb07ec0

$a301280a@phx.gbl...

Amis de Newsgroup, experts en Sql Server, bonjour.

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

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

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

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

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
technique@espacefermetures.com


.

.

.

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

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

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

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

serveur A en temps reel.

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

connecter sur le serveur B de faire des operations sur le

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


POur ton application c simple tu cree une application qui

distant via rtc ou pigeon voyageur (moins simple) et

tes données.



<anonymous@discussions.microsoft.com> a écrit dans le

355101c4a475$39add900$a401280a@phx.gbl...
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

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
technique@espacefermetures.com

-----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

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" <anonymous@discussions.microsoft.com> 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" <anonymous@discussions.microsoft.com>

écrit dans le

message de news: 0bf201c4a174$fcb07ec0

$a301280a@phx.gbl...

Amis de Newsgroup, experts en Sql Server, bonjour.

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

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

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

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

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
technique@espacefermetures.com


.

.

.