Discussion :

[Fred 57220]

Bonjour

je suis sous là dernière version de firebird 2.1.
lorsque j'essai de faire un backup , j'ai un message d'erreur (voir piece jointe)
une explication de la cause serait la bien venu svp.

Merci

Cordialement

Fred

[Artemus24]

Salut Fred 57220.

La dernière version de FireBird est la 3.0.0 et je l'utilise en test sur mon ordi.

can't format message 13:99 -- message file c:\Program files (x86)\HK_Software\firebird.msg not found.
message length error (encountered 14 expected 8).

En gros, tu as une colonne qui a été définie à 8 octets et tu veux y mettre 14 octets.
Oui, je n'utilise pas le terme de caractères qui peut porter à confusion.

Il serait intéressant de nous dire, si par hasard tu n'utilises pas UTF-8 ?
Il ne faut pas oublier que si tu as un caractère à l'affichage, celui-ci peut occuper plusieurs octets (jusqu'à trois en utf8 et jusqu'à quatre en utf8mb4) en stockage.

@+

[Fred 57220]

Bonsoir

oui la dernière version est la 3 , mais j'utilise la 2.1xx dernière version de la série 2.1.
je n'ai pas renseigné le jeux de caractère sur cette base , je corrige (WINI1252) cela en migrant vers la 2.5.
pour cela backup 2.1 et restore 2.5 .

Lorsque je fais une verification de la base par IBexpert , il ne trouve pas d'erreur.
lorsque je parcours chaque table , je n'ai pas d'erreur.



Fred

[Artemus24]

Salut Fred.

Il faut toujours renseigner le charset de ta base de données et aussi de tes tables.
Par défaut, j'utilise :

Code :

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

DEFAULT CHARACTER SET ISO8859_1;

C'est un choix personnel, bien que je travaille sur Windows.

Avec ce charset, tu as 1 caractère qui va occupé 1 octet.
Et puis tant pis pour le chinois où l'arabe.

@+

[Fred 57220]

cela n'a pas été fait sur cette table , un heritage.
je suis d'accord sur le renseignement du charset , moi c'est WIN1252.

comment puis je savoir sur quelle table le problème se pose ?

j'ai fait un parcours systématique de chaque table sans avoir de message d'erreur.

[SergioMaster]

Bonjour,

je n'ai pas renseigné le jeux de caractère sur cette base , je corrige (WINI1252) cela en migrant vers la 2.5.
pour cela backup 2.1 et restore 2.5 .

première question, c'est sur deux postes différents ou les deux installations de Firebird sont sur le même poste ?
le backup d'une base FB2.1, si j'ai bien compris, est fait avec quelle version en service ?

comment est fait la "correction" de NONE à WIN1252 ? à ma souvenance, ce n'est pas aussi simple que cela car le
ALTER CHARACTER SET charset SET DEFAULT COLLATION collation n'est proposé qu'à partir de la version 2.5 et les modifications possible avec 2.1 n'était pas recommandées

@Artemus ISO8859_1 de Firebird vs WIN1252
il faut savoir que ISO8859_1 de Firebird n'est pas celui de la norme ISO car contenant (entre autre) le caractère € donc pour un "puriste" (par exemple le programme Flamerobin le symbole de l'euro ne passe pas dans une base ISO8859_1) l'ISO8859_1 de Firebird est en fait l'ISO8859_15 aussi connue comme Latin 9 (ou encore non officiellement latin 0) donc plus proche de WIN1252 que de l'ISO8859_1 normalisé
les différences se situent ensuite dans la tranche x80 à xBE et des caractères comme par exemple : ¼½¾©®

[Artemus24]

Salut à tous.

@Artemus ISO8859_1 de Firebird vs WIN1252
il faut savoir que ISO8859_1 de Firebird n'est pas celui de la norme ISO car contenant (entre autre) le caractère € donc pour un "puriste" (par exemple le programme Flamerobin le symbole de l'euro ne passe pas dans une base ISO8859_1) l'ISO8859_1 de Firebird est en fait l'ISO8859_15 aussi connue comme Latin 9 (ou encore non officiellement latin 0) donc plus proche de WIN1252 que de l'ISO8859_1 normalisé
les différences se situent ensuite dans la tranche x80 à xBE et des caractères comme par exemple : ¼½¾©®(

Dans un sujet précédent, tu avais déjà abordé cette question Donc oui, je le savais déjà !

Ce qui me dérange, que ce soit avec MySql ou même avec FireBird, c'est le choix entre Win1252 et ISO8859_1 ou si tu préfères ISO8859_15.
Ces trois charset sont très proches les uns des autres. La question que je me pose est celle qui est la plus standard.
Vu que je suis sous windows et que je n'exporte rien, j'aurai tendance à dire Win1252.
Mais quel est l'intérêt de ISO8859_1 ou ISO8859_15 ?

@ Fred 57220 : comme le fait si judicieusement remarqué SergioMaster, dans l'ancienne version, la manipulation est difficile à faire, voire impossible.
Le mieux est de le faire au moment de la constitution du fichier de migration à partir de la commande 'gbak'.

Dans un premier temps, tu décharges ta table par un :

Code :

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

gbak -backup  ..\Data\Base.fdb  .\2.Backup.fbk  -verify  -user sysdba  -password masterkey  -y .\2.Backup.log

Ensuite, tu charges ta table modifié en faisant ceci :

Code :

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

gbak -create  .\2.Backup.fbk  ..\Data\Base.fdb   -verify  -user sysdba  -password masterkey  -fix_fss_metadata win1252  -y .\2.Restore.log

Sur ce point, SergioMaster sera plus à même de compléter la procédure à suivre.

@+

[Fred 57220]

Bonjour

J'ai deux postes l'un équipé de firebird 2.1X et un autre de firebird 2.5x
je backup sur le poste 2.1 (en service) et je restore sur le poste 2.5 (en service) -fix_fss_metadata win1252 .

j'ai eu 1 seul problème c'est cette base que j'ai eu en heritage , la base est toujours fonctionnelle et en fonctionnement, sauf que je ne peux pas la migrer.
je ne peux faire de backup.


Fred

[SergioMaster]

Bonjour,

une première remarque -fix_fss_metadata win1252 . ne change pas le charset de la base de données uniquement celui des métadatas.

La base sur 2.1 est fonctionnelle ok mais est-ce que un restore du backup fonctionnerai ? (bien entendu dans un fichier par précaution), ne faudrait t-il pas faire une réparation de cette base avant par précaution ?

// tout d'abord
// vérifier peut être fait sur la base
gfix -v[alidate] -full -n[o_update] database_name -user sysdba -password masterkey
// optionnel un sweep (normalement il est fait au cours d'un backup
gfix -s[weep] [-i[gnore]] database_name -user sysdba -password masterkey
// faire un shutdown par précaution
gfix -shut -f[orce] 0 database_name -user sysdba -password masterkey
// faire une copie du fichier fdb
// faire un restart (à ne pas oublier)
// travailler maintenant sur la copie
//réparer (attention, au mend risque de perte de données, ignore pour le checksum)
gfix -v[alidate] -full [-i[gnore]] -m[end] database_name -user sysdba -password masterkey
// procéder ensuite au backup , tester un restore en 2.1 (encore sur un autre fichier ?)

c'est tout ce que je vois comme manipulations possibles

@Artemus

Mais quel est l'intérêt de ISO8859_1 ou ISO8859_15 ?

à part que ce sont de normes ISO contrairement à WIN1252 à vrai dire je n'en ai pas idée sauf peut être qu'il y a plus de COLLATION avec ISO pas de case+accent insensitive pour win1252 alors qu'il y a FR_FR ou FR_FR_CI_AI (en ce qui nous concerne) pour ISO8859_1 , maintenant quid lorsque dans une table CLIENTS par exemple on a des clients Allemand ou Tchèques ?

pour en revenir au changement de CHARACTER SET je viens de faire l'expérience avec une "vieille base" en NONE , dialect 1(pour corser)

si le changement de DIALECT est aisé gfix -user SYSDBA -password masterkey database_name -sql_dialect 3le changement de CHARACTER SET via la commande SQL ALTER CHARACTER SET WIN1252 SET DEFAULT COLLATION WIN1252 ne donne pas le résultat escompté (à savoir toute la base en WIN1252) seul la COLLATION est changée le charset de la base reste à NONE , et c'est bien ce qu'il me semblait !

sauf avis contraire, jusqu'à présent, le seul bon moyen (et pas simple) de passer d'une base d'un CHARSET à un autre est de créer une nouvelle base puis d'y transférer les données . Ce qui n'est pas simple (d'expérience) , tout d'abord la base crée de même shéma devra 1 -n'avoir aucune contraintes ni trigger avant le transfert, 2- le transfert des données ne devra prendre en compte que les colonnes non calculées . Il y a bien des outils mais (encore une fois d'expérience) la partie 2 n'est pas prise en compte (d'où le besoin d'une bonne doc de la base et de pas mal d'huile de doigt ) . Je dois avouer m'y être heurté et pressé par d'autres projet n'avoir jamais eu le temps de le faire. J'ai même pensé en faire un GUI mais pour une utilisation restreinte était-ce valable ? ah, si j'avais eu un stagiaire sous la main, cela aurait été un bon programme de stage !


P.S. en relisant l'image écran, je dirais qu'il faudrait vérifier soit la procédure PROC_REAPPROS soit la procédure suivante (dans le DDL), en tout cas la procedure contenant les paramètres FOURNISSEUR et PRODUIT_ADR et plus ...

[alanglet]

Bonjour,

Moi quand je vois le message d'erreur qui figure en tête de cette discussion, j'y vois surtout qu'on fait référence à un fichier "c:\program files (x86)\HK_Software\firebird.msg not found.". Il me semble donc que le backup/restore n'est pas fait avec le gbak de Firebird mais avec probablement IBExpert, donc qu'il est possible que ce soit uniquement un problème IBExpert (ancienne version?).
J'essaierai d'abord de refaire ce backup/restore avec le gbak original.

André

[SergioMaster]

Bien vu je n'avais pas vu la relation entre HK_Software et IBExpert (que je n'utilise pas)

[Fred 57220]

Bonjour

j'ai essayé avec un gback directement j'ai le meme problème.
la version de ibexpert est à jour.

j'ai vérifié avec une autre base et le backup va jusqu'au bout.

j'ai supprimé toutes les procedures stockées et idem.
j'ai supprimé toutes les générateurs et idem.
j'ai supprimé toutes les vues et idem.

il me reste a supprimer table après table.

ou alors appeler un marabout.

Cordialement

[Artemus24]

Salut à tous.

... sauf que je ne peux pas la migrer. je ne peux faire de backup.

Est-ce toujours la même erreur, celle de ton premier message ?

une première remarque -fix_fss_metadata win1252 . ne change pas le charset de la base de données uniquement celui des métadatas.

Oui en effet, j'aurai dû indiquer plutôt "-fix_fss_data win1252".

à part que ce sont de normes ISO contrairement à WIN1252 à vrai dire je n'en ai pas idée

Je sais cela. Je reformule ma question : qu'est-ce que la norme ISO peut apporter en plus vis-à-vis de WIN1252 ?
Ma réponse : à vrai dire, rien de plus.

pour en revenir au changement de CHARACTER SET je viens de faire l'expérience avec une "vieille base" en NONE , dialect 1(pour corser)

Dans un autre sujet, où je ne suis pas intervenu, tu parlais du backup et du restore.
J'ai fait le test et tout c'est bien passé grâce à tes explications.

Dans ce sujet, j'ai l'intention de progresser ma compréhension sur le backup et restore, et en particulier le problème du changement du charset.

le changement de CHARACTER SET via la commande SQL ALTER CHARACTER SET WIN1252 SET DEFAULT COLLATION WIN1252 ne donne pas le résultat escompté

J'ai aussi constaté que je n'ai pas pu changer le charset de ma base.

sauf avis contraire, jusqu'à présent, le seul bon moyen (et pas simple) de passer d'une base d'un CHARSET à un autre est de créer une nouvelle base puis d'y transférer les données.

J'ai crée une nouvelle base avec le bon charset, mais quand je fais le restore, tout est écrasé. Autrement dit, je reviens à l'ancien charset.
Mon test était de fait un "show database". Et après le restore, je me suis retrouvé avec mon ancien charset de la database.
Ensuite, j'ai fait une tentative de modification du charset directement sur la base finale, mais sans succès.

Mes compétences s'arrêtent là. Il va falloir que j'approfondisse la question et faire des tas de tests.

Il me semble donc que le backup/restore n'est pas fait avec le gbak de Firebird mais avec probablement IBExpert

Pourtant dans le compte rendu donné par Fred 57220 dans son premier message, il y a bien le mot "gbak" qui se répète à chaque ligne.
A moins de me tromper, il s'agir bien de la commande "gbak". Quel est le rapport avec IEBxpert ?

Bien vu je n'avais pas vu la relation entre HK_Software et IBExpert (que je n'utilise pas)

Il faudra que l'on m'explique ce que vous avez tous vus.

j'ai essayé avec un gback directement j'ai le même problème.

Tu veux dire la même erreur que dans ton premier message.

Selon moi (à confirmer), il s'agit d'un problème de charset, comme je l'ai déjà indiqué.

@+

[Fred 57220]

Mrs Bonsoir

Oui cela bloque sur le backup en gback ou ibexpert , meme message.
j'ai crus aussi à un problème avec ibexpert donc passage en manuel.(mais non)

ce n'est pas la premiere base que je migre vers 2.5 , mais c'est la seule qui ma fait mal à la tête.

Bon dans un premier et faute de temps , j'ai récupéré une base vide et je lance un script de chargement (Adieu week-end).
il faut que la base redémarre lundi migrée.

je vous remercie de vos messages d'aide , je vous tiendrais informé de la suite.

Cordialement

Fred

[SergioMaster]

Bonjour,

Oui en effet, j'aurai dû indiquer plutôt "-fix_fss_data win1252".

bien vu, est-ce que cela a été fait

Bon dans un premier et faute de temps , j'ai récupéré une base vide et je lance un script de chargement (Adieu week-end).
il faut que la base redémarre lundi migrée.

Un dernier test avant, la base vide est une extraction des METADATAS de la base qui pose problème ou un autre DLL ? à moins que cela soit un backup sans données ? et si oui est-ce celui de la base à problème(s) ?

En tout cas bon courage, je compatis !

Je sais cela. Je reformule ma question : qu'est-ce que la norme ISO peut apporter en plus vis-à-vis de WIN1252 ?
Ma réponse : à vrai dire, rien de plus.

si les COLLATIONs mais avec la perte de certains caractères

J'ai crée une nouvelle base avec le bon charset, mais quand je fais le restore, tout est écrasé.

oui, normal, quand je disais "puis d'y transférer les données." je pensais à l'utilisation d'outils tel FBexport, FBCopy etc... à moins que une manipulation soit possible dans le fichier de backup avant (je n'ai jamais essayé mais je tenterais bien )

Il faudra que l'on m'explique ce que vous avez tous vus.

c'est dans le message d'erreur, le chemin d'accès à firebird.msg n'est pas le chemin "classique" d'installation de firebird soit C:\Program Files\Firebird\Firebird_2_5\firebird.msg, de plus il est installé dans un répertoire 32 bits c:\program files (x86)\

[SergioMaster]

à moins que une manipulation soit possible dans le fichier de backup avant (je n'ai jamais essayé mais je tenterais bien )

j'ai tenté ! avec une base (ou du moins son backup) contenant peu de données avec un éditeur hexadécimal j'ai pu passer le backup de UTF8 à NONE très facilement , il m'a fallu un peu plus de temps pour comprendre comment faire pour un charset plus long (la longueur du nom du charset se trouve devant) donc en manipulant également l'octet devant UTF8 de 04 à 07 j'ai pu mettre WIN1252 (en insérant 252)
et après restore j'avais la base reconnue comme WIN1252 . Attention, cela ne veut pas dire que les données elles sont dans le bon encodage (je ne le crois pas) il faudrait faire des essais plus poussés , mais je pense qu'une base préalablement à NONE devrait être "convertible" avec cette manip. Comme j'ai des bases de tailles assez importantes en NONE j'essaierai de faire un essai en ce sens toutefois il va me falloir un protocole de test pour faire une comparaison.

Il me semble déjà avoir vu ce genre de manip sur le net, il y a de cela une éternité

Cependant cela ne règle pas le problème du restore qui plante

[alanglet]

Bonjour,

Il y a bien longtemps aussi, j'ai utilisé Interbase DataPump qu'on peut encore trouver http://www.clevercomponents.com/down...pump/index.asp
Il permet de copier des tables d'une base à l'autre assez facilement si les structures sont semblables.

André

[Artemus24]

Salut à tous.

@ Sergiomaster : je voulais parler d'une modification du charset avec les outils standards de FireBird et non de faire une bidouille dans le backup.
La bidouille, c'est en dernier ressort, quand on a épuisé toutes les solutions standards.

Et puis, on ne fait pas des backup/restore tous les jours. Donc oui, on peut se permettre ce genre de bidouille, du moment que ça fonctionne correctement.

@+

[Fred 57220]

Bonjour

j'ai une base vierge au bon charset , et qui est clean (backup / restore ras)
j' ai fait la moitié du transfert , et à chaque fois je fais un backup / restore pour voir si problème revient et pour le moment ras.

j'avais fait un essai de vider les tables , et je pense que le problème vient de la structure , plus que des données , meme sans données le backup plante.


Cordialement

Fred

[Fred 57220]

J'ai oublié IBexpert permet de :
1) comparer les bases
2) comparer les données des bases
et de faire des scripts SQL de rechargement des données.

Fred