Charger des donées codées en EBCDIC dans une base UTF8

Version imprimable

12/10/2007, 17h35
mioux

Charger des donées codées en EBCDIC dans une base UTF8

Salut

Est ce qu'il est possible de charger un fichier formaté en EBCDIC xxx (parce qu'en plus on en a plusieurs, genre EBCDIC 870) dans une base de données dont les données sont en unicode ?

En fait je cherche la table des formats supportés par SQL Serveur au niveau des fichiers de formats, savoir s'il gère EBCDIC
12/10/2007, 19h53
kagemaru

bonjour,

vous devez les convertir avant en ASCII.

Est-ce que ces fichiers proviennent d'une base DB2 sur machines ebcdic ?
Il y a un driver (OLEDB for DB2, fourni avec MS Host Integration Service) permettant à SQL Server de lire les données directement, et ce driver lui, se charge de la conversion.
13/10/2007, 02h19
mioux

Citation:

Envoyé par kagemaru

bonjour,

vous devez les convertir avant en ASCII.

Est-ce que ces fichiers proviennent d'une base DB2 sur machines ebcdic ?
Il y a un driver (OLEDB for DB2, fourni avec MS Host Integration Service) permettant à SQL Server de lire les données directement, et ce driver lui, se charge de la conversion.

En fait il s'agit d'une extraction d'une base de données sur laquelle je n'ai aucun contrôle. On recoit les fichiers par CFT et la conversion EBCDIC -> ASCII pose problème... Du coup, on a trouvé la solution de gérer directement la transco par un programme homemade qui va convertir les fichiers d'un format à l'autre une fois le fichier recu

J'ai fais un tour rapide de SQL Server, il ne semble pas gérer EBCDIC en natif (et le driver OLEDB for DB2 ne peux pas m'interesser vu que je n'ai aucun moyen d'accéder aux données sources)
13/10/2007, 13h47
kagemaru

c'est bien dommage pour CFT, en général il convertit très bien l'EBCDIC en ASCII . Mais c'est un autre sujet :)
15/10/2007, 11h05
SQLpro

Pas de SQL Server sous la main, mais vérifiez s'il n'existe pas une collation EBCDIC auquel cas vous pouvez travailler directement vos données à ce format dans SQL Server.

A +
15/10/2007, 14h07
mioux

Il y a EBCDIC dans les interclassement de SQL Server 2005, mais apparemment, la solution a été envisagée sans succès... du coup je suis en train de développer un convertisseur de fichiers qui convertit les fichiers d'un codepage sur 1 octet, dans un codepage donné avec une table de transco personnalisée... comme ça, on pourra convertir nos divers fichiers au formats EBCDIC en UTF16 (dans la solution envisagée)

Toutefois je pense que je continuerai à chercher du coté des interclassements
15/10/2007, 17h10
kagemaru

Citation:

la solution a été envisagée sans succès

vous pouvez préciser ?
15/10/2007, 17h21
mioux

De mémoire :

Il me semble que les bases ont étés transposées en interclassement EBCDIC, mais ennsuite, il y avait des problèmes de collation avec les autres bases de données (ou alors la solution a été vaguement envisagée, mais le DBA a préféré ne pas risquer pour ne pas avoir le problème sus-cité mais je me rapelle plus, c'était la semaine dernière, et depuis j'ai fais pas mal de choses)
15/10/2007, 20h38
kagemaru

En effet, lorsque vous comparez ou joignez 2 chaines ou 2 colonnes littérales il faut que la collation soit identique au niveau de ces colonnes. Si la collation n'est précisée au niveau de la colonne (ce qui est le cas la plupart du temps), SQL Server se base sur la collation de la base.

Votre DBA devrait suivre un cours, comme ceux que rudi et moi donnons à Orsys, car la problé"matique est simpel à résoudre et votre dba n'est pas allé bien loin pour son effort de recherche.

J'ai écrit il y a bien longtemps un papier sur les collations qui est sur ce serveur :
http://sqlpro.developpez.com/cours/s...er/collations/

Démonstration de la solution : il suffit simplement de rajouter une clause COLLATE dans les requêtes pour que cela marche !
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 CREATE TABLE T_DATA_EBCDIC (COL VARCHAR(16) COLLATE SQL_EBCDIC037_CP1_CS_AS) GO INSERT INTO T_DATA_EBCDIC VALUES ('azertyuiopéàÂÖ') GO CREATE TABLE T_DATA_FRENCH (COL VARCHAR(16) COLLATE French_CI_AI) GO INSERT INTO T_DATA_FRENCH VALUES ('azertyuiopéàÂÖ') GO SELECT * FROM T_DATA_EBCDIC AS E INNER JOIN T_DATA_FRENCH AS F ON E.COL = F.COL /* sg 468, Niveau 16, État 9, Ligne 2 Impossible de résoudre le conflit de classement entre 'French_CI_AI' et 'SQL_EBCDIC037_CP1_CS_AS' dans l'opération equal to. */ SELECT * FROM T_DATA_EBCDIC AS E INNER JOIN T_DATA_FRENCH AS F ON E.COL = F.COL COLLATE French_CI_AI COL COL ---------------- ---------------- azertyuiopéàÂÖ azertyuiopéàÂÖ
A +

Citation:
Envoyé par SQLpro
Votre DBA devrait suivre un cours, comme ceux que rudi et moi donnons à Orsys, car la problé"matique est simpel à résoudre et votre dba n'est pas allé bien loin pour son effort de recherche.

J'ai écrit il y a bien longtemps un papier sur les collations qui est sur ce serveur :
http://sqlpro.developpez.com/cours/s...er/collations/

Démonstration de la solution : il suffit simplement de rajouter une clause COLLATE dans les requêtes pour que cela marche !
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 CREATE TABLE T_DATA_EBCDIC (COL VARCHAR(16) COLLATE SQL_EBCDIC037_CP1_CS_AS) GO INSERT INTO T_DATA_EBCDIC VALUES ('azertyuiopéàÂÖ') GO CREATE TABLE T_DATA_FRENCH (COL VARCHAR(16) COLLATE French_CI_AI) GO INSERT INTO T_DATA_FRENCH VALUES ('azertyuiopéàÂÖ') GO SELECT * FROM T_DATA_EBCDIC AS E INNER JOIN T_DATA_FRENCH AS F ON E.COL = F.COL /* sg 468, Niveau 16, État 9, Ligne 2 Impossible de résoudre le conflit de classement entre 'French_CI_AI' et 'SQL_EBCDIC037_CP1_CS_AS' dans l'opération equal to. */ SELECT * FROM T_DATA_EBCDIC AS E INNER JOIN T_DATA_FRENCH AS F ON E.COL = F.COL COLLATE French_CI_AI COL COL ---------------- ---------------- azertyuiopéàÂÖ azertyuiopéàÂÖ
A +
Notre DBA est en fait développeur et non DBA de formation, on a un vrai DBA, mais il ne travaille pas sur ce projet (et lui n'a pas pu nous renseigner :D)

Le problème est surtout que la base de données a mal été conçue au départ (il n'y avait pas de DBA) et maintenant on s'en mords les doigts... En fait on ne pensait pas qu'on aurait de problème avec les fichiers recus en divers formats EBCDIC (car venant de plusieurs pays)

En tout cas, je note aussi ca dans un coin :D