[Sybase] Migration de Sql Anywhere 5.5 à 7.0.2, pb de cara. [Résolu]

[onipif]

Bonjour à toutes et à tous ,

Voilà, je suis entrain de migrer des bases de données actuellement sous sql Anywhere 5.5 sous NT4 pour passer sous Sql Anywhere 7.0.2 sous Win2003 Server.

Je sais, je ne fais pas dans les dernières versions, mais licences obligent


Alors j'ai reussi à migrer une base via un unload de Sql Anywhere5 (apres avoir fait les modif' pour le changement de protocole de communication qu'il y a eu entre la version 5/inferieur et 6/superieur de Sql Anywhere) et dans le Sql Anywhere 7.0.2, j'ai donc créé le lien ODBC, une table et le service, j'arrive à lancer le serveur nouvellement créé mais par contre, lorsque j'importe le fichier unload.sql et les *.dat qui ont été générés avec le unload , tout se rempli correctement...sauf que les caractères speciaux français sont remplacés par des "..." pour les "è", "," pour les "é", "_" pour les "ù" (bon je dis cela de mémoire, c'est simplement à prendre en compte comme exemple).

Ca doit venir du système de codage de la base de données, dumoins le pensais-je mais contrairement à la version 7.0.2, dans la version 5.5, il n'y a pas de codepage à 1252...je suis en CodePage 850 (ASCII multilingu)....Est ce que celà peut venir de là ?

En tout cas, si quelqu'un peut m'aider sur cette migration, qui dans le temps est un peu depassée
Celà serait sympa, car ça fait presque 1 semaine que j'essaye de migrer une base et j'en vois de toutes les couleurs lol (comme le interactive SQL de la version 7.0.2 qui n'acceptais pas les "" pour définir la table et l'utilisateur, et ça faisait tout merdouiller, heureusement, en tout desinstallant et tout reinstallant, par magie, ce souci à disparu; ouf )

Merci à ceux qui lisent ça et encore plus à ceux qui répondent

[fadace]

oui, ca vient forcément de là. Il vous faut créer vote base cible avec le même codage que la base source.

[onipif]

ok merci bien, j'essaye ça dans la journée dès que j'ai un peu de temps libre !

Et ce n'etait pas la peine de me vouvoyer

[onipif]

fadace =>

Est-ce normal que les fichiers *.dat de l'unload ne contiennent pas d'accents mais les caractères de remplacement comme je l'ai cité dans mon premier post ? (car du coup le problème vient peut-être de l'unload, j'ai oublié de préciser ça au début :-/ )

De plus, l'obligation de ne pas mettre de guillement pour définir l'utilisateur et le mot de passe est revenue...du coup, mon fichier SQl généré par le unload n'est plus valide sauf si je remplace les guillements par un caractère vide (par rien)...mais j'ai peur que cela change quelque chose qui ne devrait pas...

De même, je voulais tester de Sql anywhere 5.5 sur NT4 à Sql anywhere 5.5 sur Windows Server 2003 mais Interactive SQL s'ouvre sous une invite de commande et là je ne peux plus rien faire

En tout cas, je pensais que cela serait bien plus simple :sweat:

[onipif]

C'est bon, c'etait à cause du pilote jconnect

Par contre j'ai toujours le problème d'encodage/decodage des caractères... je me demande si ce n'est pas lors du dechargement sous Win NT qui met "des carrés" (caractères non connus) dans les *.dat pour les accents, etc.

J'essaye de decharger sous win2000...et je vous tiens au courant si je trouve la solution...sait-on jamais, quelqu'un aura peut être plus de retard que moi

[onipif]

Puré !
En fait j'ai trouvé le problème ! Et là c'est bien la première fois que je vois ça !

En fait, mon SqlAnywhere 5.5 etait en Anglais, hors j'ai installer la version du 7.0.2 en français...

Dans les fichiers *.dat, les code ASCII des caractères speciaux (accents) correspondent bien... Mais au code ASCII AMERICAIN !!!

Table ASCII version AMERICAINE :

http://www.asciitable.com/

on voit bien que le "è" correspont au caractère 138.

Hors, avec une table ASCII en Français (je croyais que la table ASCII était justement là pour un standart Americain, europeen..hors je viens de voir que non, je ne savais même pas que 2 tables ASCII différentes existaient ! )

http://www.purebasic.com/french/documentation/Reference/ascii.html

pour le code 138, la correspondance est "Š" !!!

130 correpond à "é" en ASCII Americain et "," en ASCII français !
etc...

C'est bien mon problème mais alors là je n'y comprend plus rien !
J'ai essayé d'installer SQLAnyWhere7.0.2 en version anglaise mais j'ai le même problème ....

Si quelqu'un pouvait demeler les noeuds de ma tête car franchement je suis

Merci bien à ceux qui m'aideront...

[onipif]

Bon il y a du mieux et du pire :

En fait, via un logiciel de conversion ASCII EOM vers ASCII ANSI, j'ai traité tous les fichiers *.dat . Et là plus de problème de caractères.

Par contre, il y a des erreurs lors du traitement du unload.sql car les enregistrements avec NULL comme valeur sont remplacés par rien du tout lors du dechargement ("enregistrement1",,"enregistrement1"), SQLAnywhere n'arrivant pas à interpréter le "vide" lors de la requête (il y a un patch correctif de 40MO pour la passer en version 7.0.4 qui est sensé corriger ça mais nada, même avec CONVERSION_ERROR = Off ), j'ai remplacé tous les ,, par ,NULL, pour corriger ça.

Là toutes mes données s'importent bien !

Hors, à la création des clé etrangéres, ils n'arrivent rien à créer car des données se trouvent déjà dans les tables....
Donc encore un problème...

En plus, envoyer les données via une requete sous ISQL est accepté...ce qui est un peu n'importe quoi car c'est refusé via la requete dans le unload.sql .

Si quelqu'un à déjà eule problème des cléfs étrangères, par exemple si une option est à virer ou à ajouter, ça m'aiderai bien Car là, c'est vraiment une cascade à problèmes cette importation...mais je devrais bientôt y arriver...si ma tête tiens le choque

Merci à ceux qui m'aide.

[onipif]

Hop j'ai trouvé le blème avant hier, je ne passais pas par le pilote JCONNECT mais par un lien ODBC

Peut-être que ça aidera quelqu'un dans un certain futur