Discussion :

[Luc1an0]

Bonjour à tous,

Après avoir fait beaucoup de recherche sur la synchronisation de données entre différentes bases, j'ai fini par porter mon choix sur DTS.

A savoir que d'un côté j'ai
MSSQL : champs de type text ou ntext
MYSQL : champs text

Quand je fais une copie directe de colonnes j'obtiens une donnée inexploitable.

J'ai tenté de passer par un script VBS durant transformation avec une instruction "CStr" mais pareil.

J'ai tenté de feindre avec une requete select de ce type

Code :

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

Select CAST(monChampsNText as varchar(4000)) from matable

Mais j'ai peur d'oublier des données...

Est ce qu'il y aurait un moyen fiable de faire cela ?

[Luc1an0]

Je vais apporter un peu de précision ... et un petit récap' :

J'ai donc deux bases de données :
MSSQL 2K
MySQL

Je souhaite programmer des lots de transfert de données avec DTS. Tout fonctionne sauf pour les transferts des champs ntext (MSSQL).

Les champs ntext dans MSSQL sont des champs text dans MySQL.

Avec le driver ODBC 3.51, le transfert des données ntext se fait mais inexploitable.

Avec le driver 5.1 : les champs sont Null.

J'ai bien entendu essayer la copie de colonne directe (copy column) et le ActiveX Script avec pour le transfert de mes champs ntext, une instruction de ce type :

Code :

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

DTSDestination("MonChampsTextMySQL") = CStr(DTSSource("MonChampsNTextMSSQL"))

Mais sans résultat probants.

J'ai tenté avec le MySQL Migration ToolKit, mais de toute évidence inefficace car je dois planifier ces lots et selon des critères bien précis.

J'ai vu que certains pouvaient avoir des remontées de messages d'erreur en rapport avec le traitement de champs de types BLOB, mais ce n'est pas mon cas. Le lot s'exécute de façon correcte.

Et pour rappel, j'ai tenté un CAST(monChampsNtext as nvarchar(4000)) : ça marche ... Mais j'ai identifié plusieurs lignes ayant des champs ayant une longueur égale à 4000 (donc supérieure...) : cette solution n'est donc pas viable.

Je n'ai plus trop d'idée... Si quelqu'un avait ne serait ce qu'un début de piste, ou même n'importe quelle idée n'étant pas à 100% dans mon contexte ... : Je suis preneur.

[SQLpro]

Il faut utiliser READTEXT depuis SQL Server 2000 pour exporter ce genre de blobs. Je ne voit d'ailleurs pas l'utilité d'une telle "réplication". Si vous nous parliez de votre besoin fonctionnel ???

[Luc1an0]

Nous effectuons quotidiennement une synchronisation des données présentes sur notre intranet, vers notre extranet.

Avec la montée en charge de nos données entrantes due à une croissance d'utilisateurs, notre "synchronisation" actuelle ne répond plus à notre besoin. Du moins, elle y répond mais il y a un gros manque de performance.

[Luc1an0]

Il faut utiliser READTEXT depuis SQL Server 2000 pour exporter ce genre de blobs.

Après étude de "READTEXT" moyen quand même. Car il faut déclarer un pointeur de type varbinary avec une longueur, et c'est là tout mon souci ... : La longueur du champs.

Selon la MSDN cette fonction est à éviter, et conseille plutôt le substring, mais encore une fois, il faut toujours indiquer la fin.

ça doit pas être si compliqué que ça à traiter quand même...

Pour info', notre synchro' actuelle est basé sur du Access + table attachées sur du drivers ODBC... Oui c'est moyen mais bon... Pour l'instant ça tourne mais ça reste aléatoire par moment. Surtout qu'on a pas de remontée d'erreur.

En tout cas, Access gère bien les champs ntext ...

Est ce qu'un petit exécutable en DotNet pour gérer ce genre de champs peut être envisageable ?