Discussion :

[freud]

Bonjour,

J'ai une BDD sous FB3 déclarée en charset ISO8859_1 et souhaiterais la faire passer en WIN1252, existe-t-il un moyen SVP, de le faire d'un seul coup étant donnée que j'ai une cinquantaine de table et 90 ps ? C'est dur le faire manuellement avec les risques d'erreurs ou peut-être qu'en creant une BDD avec WIN1252 et en restaurant dessus la sauvegarde contenant l'ISO8859_1 ? Es-ce faisable ? En vous remerciant.

[SergioMaster]

Bonjour

peut-être qu'en créant une BDD avec WIN1252 et en restaurant dessus la sauvegarde contenant l'ISO8859_1 ? Est-ce faisable ?

Cette manipulation , non, la restauration restaure aussi le charset

C'est dur le faire manuellement avec les risques d'erreurs

Il n'y a AMHA pas d'autre choix, sauf à utiliser les outils non gui tel que FBcopy ou fbclone (j'ai toujours en objectif d'en écrire un plus "visuel" mais pas le temps )
sauf que pour ces deux à ma souvenance on ne peut pas copier les blobs .
Il y a aussi la solution d'utiliser IBexpert version enregistrée qui semble proposé des outils adéquats pour les transferts

[freud]

On dirait que FBclone ne reconnait pas le WIN1252 n'importe comment je ne pourrait pas l'utiliser puisque la BDD contient des BLOBS
Bon je vais encore chercher y a surement un moyen de le faire avec les tables systèmes.
Merci SergioMaster

[freud]

En effet, dans IBExpert personnel la commande Extract metadata règle le problème

-Extraction des metadata de l'ancienne BDD (ISO8859_1 ) dans un script SQL
-Création de la BDD en WIN1252 et execution du script SQL

Apparemment le CharSet et le Collate des tables et PS sont toutes en WIN1252 dans la nouvelle BDD.
Pour le Collate faut-il maintenir le WIN1252 ou bien opter pour un autre Collate ? Lequel SVP ?
Cela, c'est suite à mes recherches où suis tomber sur des posts (les votres par exemples) où il est dit qu'il faut préférer le WIN1252 au lieu de ISO8859_1 qui n'accepte pas certains caractères accentués. Bon puisque je ne suis pas encore en mode production donc je ne peux pas savoir.

Encore merci.

[SergioMaster]

Re,

-Extraction des metadata de l'ancienne BDD (ISO8859_1 ) dans un script SQL
-Création de la BDD en WIN1252 et execution du script SQL

ça, même flamerobin peut le faire

dans IBExpert personnel

Quand je parlais de IBExpert version enregistré c'était pour la copie de données dont les blobs

Apparemment le CharSet et le Collate des tables et PS sont toutes en WIN1252 dans la nouvelle BDD.

modifier le Charset d'une table ou d'une colonne est possible

Cela, c'est suite à mes recherches où suis tomber sur des posts (les votres par exemples) où il est dit qu'il faut préférer le WIN1252 au lieu de ISO8859_1 qui n'accepte pas certains caractères accentués.

avec les polémiques attenantes : "ISO8859_1 ANSI est différent de ISO8859_1 de Firebird"

Pour le Collate faut-il maintenir le WIN1252 ou bien opter pour un autre Collate ? Lequel SVP ?

ça peut dépendre de ce qui est voulu, c'est AMHA le point noir de Win1252 par rapport à ISO8859_1
voir tableau

[Artemus24]

Salut à tous.

J'ai une BDD sous FB3 déclarée en charset ISO8859_1 et souhaiterais la faire passer en WIN1252

Il y a peu de différences entre ces deux charsets.
Je suppose que vous êtes sous windows et que vous avez des problèmes avec certains caractères, comme le '€'.
Donc pourquoi changer de charset ?

existe-t-il un moyen SVP, de le faire d'un seul coup étant donnée que j'ai une cinquantaine de table et 90 ps ?

Un backup puis ensuite un restaure.

je ne pourrais pas l'utiliser puisque la BDD contient des BLOBS

Si vous avez des blobs, ce n'est pas en effet la solution.

où il est dit qu'il faut préférer le WIN1252 au lieu de ISO8859_1 qui n'accepte pas certains caractères accentués.

Quand on travaille sous windows, il vaut mieux être de bout en bout en Windows-1252. Pourquoi ?
A cause des conversions de charset où vous pouvez perdre certains caractères.
Par exemple, le '€' n'existe pas dans ISO-8859-1 alors qu'il existe sous ISO-8859-15 et sous Windows-1252.

Pour le Collate faut-il maintenir le WIN1252 ou bien opter pour un autre Collate ?

Non, mettre Win1252 pour le collate, c'est très bien.

@+

[freud]

Salut Artemus24,

Quand je parlais de IBExpert version enregistré c'était pour la copie de données dont les blobs

Désolé, j'avais compris la création de champs blob
En ce qui concerne flamerobin, je ne l'ai pas trop utiliser donc je n'ai pas vu cette option qu'IBEXPERT contient. J'ai toujours utiliser IBEXPERT Personnel depuis FB2 et donc habitué avec cet outils.

Je suppose que vous êtes sous windows et que vous avez des problèmes avec certains caractères, comme le '€'.
Donc pourquoi changer de charset ?

Parce que hier toute la journée j'ai galéré avec un message String truncation,Character transliteration failed, etc...
Le problème venait du fait que je me connecter avec WIN1252 tandis que la BDD etait en ISO8859_1 et comme j'ai vu
cette polémique sur les CharSets ISO8859_1 et WIN1252 et de la préférence pour le second alors j'ai décider de changer
carrément de Charset pour être tranquille à l'avenir ne sachant ce qui me peut arriver avec ISO8859_1 en mode production.

Non, mettre Win1252 pour le collate, c'est très bien.

C'est parfait alors je suis tranquille
Merci Artemus24 et SergioMaster

[SergioMaster]

Bonjour,

rien n'empêche dans une base de données win1252 de mettre certaines colonnes en un autre charset (i.e. ISO8859_1) pour profiter des Collations de ce dernier.

@Artemus

Un backup puis ensuite un restaure.

non, cette opération écrase le Charset de la SGBD pour y mettre celui contenu dans le backup (hélas)

[vanquish]

Bon je vais encore chercher y a surement un moyen de le faire avec les tables systèmes.

J'ai déjà été confronté à ce problème et nous avions effectivement trouvé une solution de ce type.
Je ne sais plus de quel charset, ni de quelle collation on partait, mais on voulait de l'ISO8859_1 FR_FR.

Nous n'avons pas rencontré de problème avec cette solution, mais je ne suis pas certain de pouvoir la recommander.
C'est assez ancien (FB 2.0) et ne peut garantir que cela fonctionne sur des bases plus récentes.
J'imagine que le charset de départ était proche, car bien entendu la méthode ne touche pas aux données déjà stockées.

A toutes fins utiles, mais sans garantie :

Code :

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

1
2
3
4
5
6
7
8
9
UPDATE RDB$DATABASE SET RDB$CHARACTER_SET_NAME = 'ISO8859_1';
 
UPDATE RDB$FIELDS RDB SET rdb$character_set_id = 21 where rdb$character_set_id = 53; 
 
UPDATE RDB$RELATION_FIELDS SET
RDB$COLLATION_ID = 4       
WHERE (RDB$COLLATION_ID = 0) ;
 
COMMIT WORK ;

[freud]

Bonjour à tous,

rien n'empêche dans une base de données win1252 de mettre certaines colonnes en un autre charset (i.e. ISO8859_1) pour profiter des Collations de ce dernier.

Merci bon à savoir mais je préfère m'en tenir à WIN1252 pour eviter des complications puisque Atermus24 semble en avoir l'habitude avec.

A toutes fins utiles, mais sans garantie :

Merci aussi et merci à tout le monde.

[Artemus24]

Salut Freud.

Parce que hier toute la journée j'ai galéré avec un message String truncation,Character transliteration failed, etc...

Quel est le rapport entre votre charset ISO_8859_1 et le fait que votre chaîne de caractères est tronquée ?
Si vous mettez une chaine de 10 caractères dans une colonne de 5 caractères, je peux comprendre.
Mais normalement ISO_8859_1, WINDOWS_1252 sont des charsets où 1 caractère = 1 octet, à l'inverse de UTF_8 qui peut aller de 1 à 3 octets.

Le problème venait du fait que je me connecter avec WIN1252 tandis que la BDD etait en ISO8859_1 ...

En effet, si vous utilisez des caractères dans l'un des charsets et que vous convertissez votre chaîne dans l'autre charset, il se peut que vous perdiez quelques caractères.
Il y a deux solutions à cela :
--> ne pas utiliser les caractères pouvant poser des problèmes.
--> travailler de bout en bout avec le même charset.

cette polémique sur les CharSets ISO8859_1 et WIN1252 et de la préférence pour le second alors j'ai décider de changer
carrément de Charset pour être tranquille à l'avenir ne sachant ce qui me peut arriver avec ISO8859_1 en mode production.

Cette polémique est entre SergioMaster et moi-même, et ne vient en aucune façon remettre quoi que ce soit en cause du fonctionnement de FireBird.
Il y a que nous ne tavaillons pas exactement de la même façon, d'où cette divergence d'opinion au sujet des charsets.

Le choix du charset (et du collate) doit se faire lors de la création de la base de données et pas après.
Si votre système d'exploitation est windows et que vous travaillez qu'avec le français et l'anglais, le mieux est d'utiliser Windows-1252 de bout en bout.
Maintenant, je ne connais pas vos contrainte, mais parfois, au lieu d'utiliser tel caractère, ne serait-il pas plus judicieux de prendre son équivalent dans la norme html ?
Par exemple le caractère '€' correspond à '€' en html, ou bien '& #8364 ;', '€', '& #128 ;'.

@+

[freud]

Bonjour Artemus24,

Quel est le rapport entre votre charset ISO_8859_1 et le fait que votre chaîne de caractères est tronquée ?

Franchement je ne sais pas. Je n'ai pas trop creusé sur les CharSet mais ca ne veut pas dire que la chaine etait tronquée. Le message exact etait:

Code :

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

1
2
3
 
Exception class in EUIBError with message arithmetic exception, numeric overflow or string truncation. 
Cannot transliterate character between  charracter sets. Arithmetic overflow or division by zero has occured.

Sur la cinquantaine de tables je n'ai pas eu ce problème et il a fallut que j'en rajoute une toute simple avec deux champs et là ca casse. Peut-être à cause des données contenant des parenthèses ? j'en doute..... Alors j'ai modifier le charset dans la chaine de connexion en mettant celui de la BDD. Comme je l'ai dit, la BDD est en ISO_8859_1 et depuis le début du dev de la BDD et je me connecter avec WIN1252 en fait au début j'etait peut-être indécis pour le choix du charset définitif et avais laisser trainer cela. Le hic, sous IBEXPERT y a pas ce problème dans la ps qui fait le select donc je pense que c'est dû au clientdataset depuis delphi que j'utilise pour rapatrier les données.

Il y a deux solutions à cela :
--> ne pas utiliser les caractères pouvant poser des problèmes.
--> travailler de bout en bout avec le même charset.
Le choix du charset (et du collate) doit se faire lors de la création de la base de données et pas après.

Merci Artemus24 pour ces conseils. En effet, faut faire simple pour eviter les complications.

[SergioMaster]

Bonjour,

Exception class in EUIBError with message arithmetic exception, numeric overflow or string truncation.
Cannot transliterate character between charracter sets. Arithmetic overflow or division by zero has occured.

cette erreur effectivement peut survenir si le système ne trouve pas de correspondance entre les deux tableaux (charset) de caractères

pour en revenir à la "polémique" il s'agit uniquement d'un problème d'interprétation due à ce qu'on fait les concepteurs de Firebird au moment de la sortie de la norme (N)ISO8859_15 : au lieu de créer la possibilité d'un nouveau CHARSET du même nom ils ont préféré prendre ce dernier pour le mettre en lieu et place de (N)ISO8859_1

je met le préfixe (N) pour norme, (F) pour tableau de caractères Firebird
on se retrouve donc avec (F)ISO8859_1 égal à (N)ISO8859_15
d'où la confusion de langage quand on parle du CHARSET il est franchement dommage qu'à l'époque ils aient choisi cette solution plutôt que de créer un nouvel intitulé (F)ISO8859_15 sans toucher à (F)ISO8859_1

il a fallut que j'en rajoute une toute simple avec deux champs et là ça casse. Peut-être à cause des données contenant des parenthèses ? j'en doute...

moi aussi ! plutôt un caractère dans ce groupe (ceux qui sont à blanc dans la colonne ISO8859_15) ou de ce groupe différence entre (N)ISO8859_1 et (N)ISO8859_15
D'expérience j'aurais un préférence marquée pour le second groupe, j'ai déjà eu des soucis de ce genre avec des ¼,½ et ¾

il aurait été intéressant de faire plusieurs essais sans changer la base :
- Changer le charset de ces 2 colonnes en WIN1252
- retrouver quelles données lèvent l'erreur
et/ou nous fournir la description de la table et un script de remplissage des données de cette table


N.B. je n'avais pas cité la méthode de vanquish justement à cause cette possibilité d'erreur

[freud]

Bonjour,

il aurait été intéressant de faire plusieurs essais sans changer la base :

Effectivement et je pense avoir trouver d'ou ca vient.



DDL de la table :

Code :

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

1
2
3
4
5
 
CREATE TABLE GRADE (
    GRADE_ID        INTEGER NOT NULL,
    INTITULE_GRADE  VARCHAR(50)  (en ISO8859_1)
);

1-Insertion avec champ en ISO8859_1 Sous IBEXPERT

Code :

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

1
2
3
 
INSERT INTO GRADE (GRADE_ID,INTITULE_GRADE)  VALUES (1,'Agent administratif');
INSERT INTO GRADE (GRADE_ID,INTITULE_GRADE)  VALUES (2,'Ingénieur d’Etat en Informatique');

Les deux INSERT passe bien.

2-Insertion avec champ en WIN1252 sous IBEXPERT

Code :

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

1
2
3
 
INSERT INTO GRADE (GRADE_ID,INTITULE_GRADE)  VALUES (1,'Agent administratif');
INSERT INTO GRADE (GRADE_ID,INTITULE_GRADE)  VALUES (2,'Ingénieur d’Etat en Informatique');

Pour la 2eme insertion ca ne passe pas avec message :

Code :

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

1
2
3
4
 
Arithmetic overflow or division by zero has occurred.
arithmetic exception, numeric overflow, or string truncation.
Cannot transliterate character between character sets.

Mais si j'enleve l'apostrophe d'etat ca passe:

Code :

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

1
2
 
INSERT INTO GRADE (GRADE_ID,INTITULE_GRADE) VALUES (2,'Ingénieur dEtat en Informatique');

Curieux..... non ?

[alanglet]

Bonjour,
Je ne sais si c'est une particularité de Firebird, mais les erreurs de charset ne sont détectées pour l'essentiel que lorsqu'il y a translitération, par exemple lorsqu'on doit copier un champ d'un charset donné dans un champ d'un autre charset, ou plus fréquent, lorsque le charset du champ est différent du charset de la connexion (ce que révèle l'EUIBERROR).
https://fr.wikipedia.org/wiki/ISO/CEI_8859 confirme bien que notre symbole € euro a été introduit dans le jeu ISO8859_15 et ne figurait pas dans l'ISO8859_1.
Pour voir si l'ISO8859_1 de Firebird contient ce symbole, vous pouvez faire l'expérience d'insérer ce symbole dans un champ ISO8859_1 à l'aide d'IBExpert puisque vous le possédez.
Si dans les paramètres de connexion à la base vous avez sélectionné le jeu de caractères ISO8859_1 comme dans le champ où vous voulez écrire, vous n'aurez pas de problème pour y insérer le symbole euro. Mais si maintenant vous changez le paramètre de connexion en WIN1252, lors de la tentative d'insertion vous obtiendrez le message d'erreur:
Arithmetic overflow or division by zero has occurred.
arithmetic exception, numeric overflow, or string truncation.
Cannot transliterate character between character sets.
Il me semble que cette expérience contredit l'affirmation précédente de Sergio.
Concernant le jeu de caractères à utiliser, sauf autre utilisation il doit être celui que l'utilisateur compose à partir de son clavier. Si vous utilisez nos versions de Windows, c'est donc bien WIN1252 qu'il faut utiliser. Quand à la collection à utiliser, il n'est pas évident que la collection WIN1252 par défaut soit celle qui correspond à vos besoins. Il existe les collections PXW_INTL et PXW_INTL850 qui en diffèrent en particulier par l'ordre de tri (classant les lettres accentuées à la suite des lettres non-accentuées correspondantes et non après toutes les lettres par défaut) et par la mise en majuscules des caractères accentués (avec ou sans accent). Je regrette seulement que l'appellation de ces collections ne reprenne pas l'appellation actuelle avec "ai" et "ci" qui me semble plus claire.

André

PS: pour insérer une apostrophe en sql il faut la doubler...

[SergioMaster]

Bingo, il s'agit bien de mon "deuxième groupe" code B4 (Acute Accent)

[Artemus24]

Salut Freud.

J'ai fait votre test et en effet, je reproduis bien la même erreur que vous.
Mais je dois expliquer ce que j'ai fait afin de bien cerner le problème que vous rencontrez.

Voici mon script batch windows qui permet d'exécuter le script sql firebird :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@echo off

chcp 1252 > nul

SET FIC=%~nx0
SET FIC=%FIC:bat=sql%

IF EXIST ..\Data\Base.FDB  del /F ..\Data\Base.FDB

isql  -charset WIN1252  -echo  -input %FIC%  -quiet  -password 'masterkey'  -role RDB$ADMIN  -user 'sysdba'

@echo.
pause
exit

Que remarque-t-on ?
Que j'utilise le charset WIN1252 pour l'affichage à la console du résultat produit par le script sql firebird.

Et voici le résultat :

Code :

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

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
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET ISO8859_1;
 
CREATE TABLE GRADE (
  GRADE_ID        INTEGER       NOT NULL,
  INTITULE_GRADE  VARCHAR(50)   COLLATE ISO8859_1
);
 
COMMIT;
 
INSERT INTO GRADE (GRADE_ID,INTITULE_GRADE)  VALUES (1,'Agent administratif');
INSERT INTO GRADE (GRADE_ID,INTITULE_GRADE)  VALUES (2,'Ingénieur d’Etat en Informatique');
Statement failed, SQLSTATE = 22018
arithmetic exception, numeric overflow, or string truncation
-Cannot transliterate character between character sets
After line 10 in file Base.sql
 
COMMIT;
 
select* from GRADE;
 
    GRADE_ID INTITULE_GRADE
============ ==================================================
           1 Agent administratif
 
 
EXIT
 
Appuyez sur une touche pour continuer...

Rien de surprenant. Si maintenant, je change le charset du batch et que je mette ISO8859_1, l'erreur disparait !

Code :

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

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
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET ISO8859_1;
 
CREATE TABLE GRADE (
  GRADE_ID        INTEGER       NOT NULL,
  INTITULE_GRADE  VARCHAR(50)   COLLATE ISO8859_1
);
 
COMMIT;
 
INSERT INTO GRADE (GRADE_ID,INTITULE_GRADE)  VALUES (1,'Agent administratif');
INSERT INTO GRADE (GRADE_ID,INTITULE_GRADE)  VALUES (2,'Ingénieur d’Etat en Informatique');
 
COMMIT;
 
select* from GRADE;
 
    GRADE_ID INTITULE_GRADE
============ ==================================================
           1 Agent administratif
           2 Ingénieur d’Etat en Informatique
 
 
EXIT
 
Appuyez sur une touche pour continuer...

Donc c'est bien un problème de conversion de caractères, considérée comme illicite.
Alors comme résoudre ce problème ? En mettant le bon caractère !

En ce qui concerne votre apostrophe, j'utilise le code ascii 39 (en décimal).
C'est le caractère qui se trouve sur la touche 4 de ton clavier "azerty".
Si vous désirez mettre une apostrophe dans une chaîne de caractères, il faut la doubler !

Ce qui donne :

Code :

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

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
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET ISO8859_1;
 
CREATE TABLE GRADE (
  GRADE_ID        INTEGER       NOT NULL,
  INTITULE_GRADE  VARCHAR(50)   COLLATE ISO8859_1
);
 
COMMIT;
 
INSERT INTO GRADE (GRADE_ID,INTITULE_GRADE)  VALUES (1,'Agent administratif');
INSERT INTO GRADE (GRADE_ID,INTITULE_GRADE)  VALUES (2,'Ingénieur d''Etat en Informatique');
 
COMMIT;
 
select* from GRADE;
 
    GRADE_ID INTITULE_GRADE
============ ==================================================
           1 Agent administratif
           2 Ingénieur d'Etat en Informatique
 
 
EXIT
 
Appuyez sur une touche pour continuer...

Et là, le problème est résolu. Bien sûr, je suis repassé en WIN1252 pour que le test fonctionne correctement.

@+

[alanglet]

Bingo, il s'agit bien de mon "deuxième groupe" code B4 (Acute Accent)

Comme moi qui pensait voir une apostrophe (qui ne serait pas passée sans être doublée non plus en ISO8859_1), vous vous trompez en croyant voir l'accent aigüe #180 ou #$B4.
Il s'agit du #146 ou #$92 qui figure dans le jeu WIN1252 mais non dans ISO8859_1 ni dans ISO8859_15.

André

[alanglet]

Rien de surprenant. Si maintenant, je change le charset du batch et que je mette ISO8859_1, l'erreur disparait !

Normal: dans le premier cas le jeu de connexion WIN1252 étant différent du jeu du champ ISO8859_1 il y a translitération. Le caractère #146 n'existant pas en ISO8859_1 est refusé.
Dans le second les jeux de caractères de connexion et du champ ISO8859_1 sont identiques: il n'y a pas de translitération et le caractère #146 peut passer bien que ne figurant pas dans ce jeu.

André

[Artemus24]

Salut à tous.

Ça nous fait trois apostrophes différentes à gérer :
--> 0x27 (déci 39) --> table ASCII
--> 0x92 (déci 146) --> WINDOWS_1252
--> 0xB4 (déci 180) --> ISO_8859_1

Le mieux est d'utiliser l'apostrophe de la table ascii.

Utiliser au maximum les caractères de la table ascii car ils sont présents dans tous les charset.

@+