Bonjour,
 
J'ai un petit soucis concernant les variables BLOB.
En fait, j'execute une réplication d'une base SQL server dans une base mysql en passant par sql server.
J'ai créé une chaine ODBC pour pouvoir faire le lien entre les deux. Lors de l'execution de l'étape, j'ai eu le message d'erreur qui dit:  
 
"Le nombre de lignesqui ont échoué excède le maximum spécifié.  
Ni l'insertion ni la mise a jour basée sur une requête des valeurs BLOB ne sont prises en charges".
 
 Les types des valeurs de ma bases sql server sont les suivants: tyint, numeric, varchar, datetime, bit, integer et long varchar. Après une petite recherche, j'ai cru comprendre que les valeurs BLOB devaient être celles de type long, donc ici lond varchar. Est ce bien cela?
 
J'ai donc essayé d'executer l'étape en enlevant la réplication des variables de type 'long varchar' pour les tache qui n'ont pas marché. Et la, cela marche.
Je suppose donc que cela était bien du au valeur de type varchar. Pourtant sur 4 taches, 2 n'avaient par marchées. Or les 2 qui avaient fonctionnées contenaient une valeur de type varchar. Sauriez vous pourquoi elles ont tout de même fonctionnées?
 
De plus, il y a des valeurs de type 'long varchar' que j'ai enlevé de la réplication pour que cela puisse fonctionner mais que j'ai absolument besoin dans ma nouvelle base. Comment je pourrais faire que la réplication marche?
 
 
 
Mon problème est assez urgent parce que j'en ai besoin pour mon boulo pour mon entreprise.
Si je n'ai pas été assez précise ou claire, n'hésitez pas à me poser des questions.
 
Merci d'avance pour vos réponse.
 
Bénédicte

BLOB n'est pas supporté par le drivers ODBC de MySQL.
 
Et à vrai dire, la plupart des drivers ODBC ont bien du mal avec ce format.
 
Sinon, "long varchar", je sais pas ce que c'est, mais au mieux, c'est un "CLOB" (ou "TEXT" sous SQL Server)

ok, et il n'y a pas de solution pour que cela puisse passer?
Comment est ce que je peux faire du coup?
Tu dis que la plupart de sdrivers ODBC ont du mal, et ou est ce que je pourrais trouver un driver avec lequel ça passerait?
 
Merci!

Y'a pas de "liste". C'est au cas pas cas.
 
Par exemple, les drivers ODBC de SQL Server 7.0 (ok, ça date un peu) provoque une erreur si un champ d'un type "normal" se situait après un champ de type BLOB dans une clause select (ça, c'est ze bug qui tue, que tu mets 10 ans à trouver)
 
Le plus simple, c'est de faire abstraction de la base de données.
Un BLOB/CLOB, c'est avant tout un moyen d'affranchir l'utilisateur de séparer des ressources fichiers de ses ressources données : on stock directement de gros volumes d'informations dans la base, plutôt que de les stocker sous forme de fichiers.
 
Le plus simple, c'est donc de refaire la manipulation inverse : créer des fichiers contenant le contenu des BLOB, puis les transférer en tant que tels vers le nouveau serveur, avant de les réimporter dans des BLOB.
 
Y'a pas de solution "toute belle toute propre".
 
Je tiens quand même à préciser que si pour un certain nombre de cas, les BLOB/CLOB sont très intéressants, ils n'en restent pas moins systématiquement déconseillés par tous les SGBD. Et c'est généralement les problèmes d'interropérabilité qui sont mis en avant (par exemple, entre deux serveurs SQL Server 2005, avoir des champs "image" ou "text" dans une table implique de très grosses limitations quant à la réplication, et c'est écrit à toutes les sauces dans la documentation du produit.
Idem pour Oracle, qui n'offre même pas un outils capable de manipuler ces types de champs en ligne de commande (SQL+ gère les BLOB/CLOB comme une merde, en limitant leur taille de façon ridicule, et en n'offrant aucun moyen de manipuler de flux binaires en mode caractère).
 
Etc.
 
Bref, erreur de conception, faut assumer maintenant, et retrousser ses manches. En tout cas, bon courage.
 
Avec un gros coup de pot, tu vas trouver un autre drivers ODBC (t'as essayé OLEDB ?)... Sinon à la mano, pas le choix.

ok, merci pour tes explications, je vais essayer avec d'autres drivers(on ne sait jamais, peut être que j'aurai de la chance!). Sinon, et bien on verra...