Discussion :

[Samish]

Bonjour,

1-Postulat de base :
Server A distant : contenant une " table source" - Ex. TA01
Server B : contenant une table -Ex TB01- de données qui doivent
être associées aux fiches de la Table TA01.

Actions : recherches multicritères (+50) sur la TA01, avec ajout d'infos
complémentaires venant de TB01

2-Ce qui me paraissait logique :
- Créér des Vues sur le Server B -Jointures de TA01 sur TB01-
Est-ce illogique sous SQL Server 2000 ?

3-Problématique :
On me dit que pour des raisons de sécurité, le Serveur A ne pourra pas être
directement "lu"

> On me propose un webservice ! ??
Je croyais que le web service ne pouvait retourner que de l'XML ou de l'html.
Me trompe-je ?
Si non, ce sera inadapté aux recherches muticritères et jointures, non ?

> On me prosose aussi la création de dump pour l'import dans la DB du
server B !?
Je vois déjà à l'horizon se pointer de gros pb, et la complication des process

4- Je pense que la création d'une seconde instance sql server sur le server B,
avec un "read only" serait la solution.
Me trompe-je ?

Pourriez vous svp m'éclairer.
Merci à ce qui prendront le temps de me lire/répondre.

Samish

[Invité]

Sur chacun des serveurs, ajoute un serveur lié : serveur A lié à B, et inversement.

Dans tes requêtes, précise le nom des table pleinement qualifié:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

linkedserver.database.user.table

Pour lier les serveur, utilise la procédure sp_addlinkedserver

[Samish]

Bonjour,

Merci de votre réponse.

Mais comment pourrais-je lier le serveur A au serveur B, puisque que
je ne peux accéder directement au serveur A .

C'est pourquoi je parlais d'une nouvelle instance SQL Serveur sur le serveur B.

[Invité]

Aucun accès du tout ? Pas de possibilité d'avoir un login dessus ?

[Samish]

Alut,

Merci de votre aide

Voila le texte :
---------------------------------
You are right, our site holds it's data in a MS SQL Server, but this
Server will never be reachable from outside, because of restrictions of our
provider (security reasons).

So we will need to exchange the data by another
way. By the way, the datas are managed by a special database add-on, for
versionalization and modification logging. So there wouldn't be flat tables,
simply to read from. The access must be done by a specialized API.

A possible way to access the data, could be a "webservice" (which could be
developed by us), you can request data in XML structured manner. Another way
could by a scheduled export process, which could extract the data in a
wanted format (e. g. CSV, TAB, XML)
------------------------------

->"request data in XML structured manner" ????
Si je comprends bien il me retourne un flux XML.

->"The access must be done by a specialized API"
Si je comprends bien, je peux pas requeter en SQL, ni rien lier ?

Je suis **** pour recup le données, c'est ça ?

Samish

[Invité]

Tu n'as plus qu'à accepter les données en XML, et les importer dans une table du serveur B, et requêter dessus.

[WOLO Laurent]

On tout cas, dans ces conditions là, vous n'avez plus une seule bricole à faire.
Vous devez accepter leur solution puis que se sont eux qui pilotent !

[Samish]

Bonjour Messieur

Merci de votre aide,

j'avais -malheureusement- bien compris, le pire c'est que pour
la mise à jour de mes tables, je ne peux même pas utiliser un DTS. Pfff.

A/ Dans ces conditions, au niveau des perfs et "stabilité" des process,
une mise à jour à partir de flux XML est elle réaliste et surtout fiable ?

B/ Selon moi, accepter ces conditions c'est se fo*tre dans la m*rd*
Qu'en pensez vous ?


Samish

[Invité]

Pour la question A, il n'ya pas de problème. Le process est fiable.

Pour la B...... ça a l'air de ressembler à ce que tu dis...

[Samish]

Merci de vos lumières.