Discussion :

[sevyc64]

Bonjour,

JE tente de créer une table dans une base Firebird 2.5 et je me mange systématiquement le message d'erreur suivant :

unsuccessful metadata update
cannot create index PK_ZZZZZZZZ_GACTES

Je ne comprend, pas, j'ai pourtant déjà créer des tables, et celle-ci n'est pas des plus complexe.
Que je fasse par l'assistant du manager (j'utilise DatabaseWorkbench) ou via requête c'est pareil (logique puisque c'est au final la même requête qui est exécutée)

Le DDL :

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE ZZZZZZZZ_GACTES 
(
  GACTE_PK                   INTEGER         NOT NULL,
  GACTE_NOM                  VARCHAR(   255)  COLLATE NONE,
  GACTE_FAMILLE              INTEGER         DEFAULT 0,
  GACTE_IMAGE                VARCHAR(   255)  COLLATE NONE,
  GACTE_ABREGE               VARCHAR(    50)  COLLATE NONE,
 CONSTRAINT PK_ZZZZZZZZ_GACTES PRIMARY KEY (GACTE_PK)
);

EDIT : J'ai oublié de dire que j'ai déjà fait une réparation de la base, un backup/restore, ça ne change rien, j'ai fouiller dans les tables systèmes, je n'ai pas su voir de problème particulier pouvant me mettre sur la voie.

[makowski]

il y a peut être déjà un objet qui se nomme PK_ZZZZZZZZ_GACTES

[sevyc64]

Ben je pense avoir regarder partout, je ne le vois pas.

En fait ce n'est pas sur l'objet lui-même qu'il plante mais sur la création de l'index. J'ai testé en enlevant la création de la clé primaire et j'ai l'erreur reportée sur les index que je crée par la suite.

[Artemus24]

Salut à tous.

J'ai fait le test, sans rien changer à la création de la table.
Au prélable, j'ai créé ma base de données.

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
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET NONE;
 
-- ======================================
-- Création de la table 'ZZZZZZZZ_GACTES'
-- ======================================
 
CREATE TABLE ZZZZZZZZ_GACTES
(
  GACTE_PK                   INTEGER         NOT NULL,
  GACTE_NOM                  VARCHAR(   255)  COLLATE NONE,
  GACTE_FAMILLE              INTEGER         DEFAULT 0,
  GACTE_IMAGE                VARCHAR(   255)  COLLATE NONE,
  GACTE_ABREGE               VARCHAR(    50)  COLLATE NONE,
 CONSTRAINT PK_ZZZZZZZZ_GACTES PRIMARY KEY (GACTE_PK)
);
 
exit;
 
Appuyez sur une touche pour continuer...

Aucun problème !

Maintenant, je vais créer ma base de données en UTF8.

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
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET UTF8;
 
-- ======================================
-- Création de la table 'ZZZZZZZZ_GACTES'
-- ======================================
 
CREATE TABLE ZZZZZZZZ_GACTES
(
  GACTE_PK                   INTEGER         NOT NULL,
  GACTE_NOM                  VARCHAR(   255)  COLLATE NONE,
  GACTE_FAMILLE              INTEGER         DEFAULT 0,
  GACTE_IMAGE                VARCHAR(   255)  COLLATE NONE,
  GACTE_ABREGE               VARCHAR(    50)  COLLATE NONE,
 CONSTRAINT PK_ZZZZZZZZ_GACTES PRIMARY KEY (GACTE_PK)
);
Statement failed, SQLSTATE = 22021
unsuccessful metadata update
-CREATE TABLE ZZZZZZZZ_GACTES failed
-Dynamic SQL Error
-SQL error code = -204
-COLLATION NONE for CHARACTER SET UTF8 is not defined
After line 1 in file Base.sql
 
exit;
 
Appuyez sur une touche pour continuer...

Le "COLLATE NONE" fonctionne qu'avec le charset "NONE".

A lire : http://www.destructor.de/firebird/charsets.htm

Question : quel est l'intérêt de mettre aucun charset ?

@+

[sevyc64]

Salut à tous.

J'ai fait le test, sans rien changer à la création de la table.
Au prélable, j'ai créé ma base de données.

Aucun problème !

Idem pour moi sur une base identique mais d'un autre client, ça passe.
C'est bien ma base de test qui a un problème.
Maintenant reste à savoir si c'est spécifiquement cette base ou si je vais rencontrer le problème lors des mises à jour chez une partie des clients!

Le "COLLATE NONE" fonctionne qu'avec le charset "NONE".

A lire : http://www.destructor.de/firebird/charsets.htm

Question : quel est l'intérêt de mettre aucun charset ?

@+

Bonne question !
JE me suis contenter de faire cette table de structure identique à une autre table déjà existante qui stocke déjà des données similaires.
J'ignore pourquoi ces charset et autres subtilités, rien n'est écrit, il n'y a aucune documentation sur cette base, aucun mcd etc...
Et personne dans la boite n'est capable d'expliquer le pourquoi du comment de ce genre de chose.

Par exemple on a un champ texte dans une table (c'est le seul dans toute la base) avec un charset russe sans que personne soit capable de dire pourquoi, alors que l'on n'a pas , et que l'on n'a jamais eu de clients russophiles. Quant à corriger le tir, personne ne veut prendre la responsabilité de la décision.
Autre incohérence, le logiciel est développé par rapport à une base en Dialect 3, or on a la moitié des clients avec les bases encore en Dialect 1, mais pire, dans le logiciel on force le Dialect 1 à l'ouverture de la base dans le IbQuery.
Là c'est pareil, il faut changer les choses, mais soi-disant que l'on ne peut pas le faire comme ça, faut d'abords faire des tests, etc ... Ca fait plus de 2 ans que l'on en parle, c'est toujours pas planifié.

Et tous les jours, il faut se battre avec ce genre de choses

JE vais voir en virant le charset ou en mettant quelque chose de plus cohérent.

[sevyc64]

Bon après un énième backup/restore/validation& repair sur ma base, le script a fini par passer sans problème.

Mais je vais quand même regarder ce problème de charset.

[Artemus24]

Salut sevyc64.

Je n'ai aucune idée de l'intérêt de mettre le charset à "NONE".
Peut-être pour garder une souplesse dans l'usage des charset.
Si dans la même table, tu veux faire cohabiter plusieurs charsets différents ou encore les problèmes de tris.
En général, on utilise le charset UTF8, qui répond aux multilingues.

le logiciel est développé par rapport à une base en Dialect 3, or on a la moitié des clients avec les bases encore en Dialect 1

La différence entre Dialect 1 et 3, je n'en ai aucune idée non plus.
Je suis en dialect 3, car j'utilise la version FireBird 3.0.0.
Je suppose que c'est pour rester compatible avec des anciennes versions comme Interbase avant 6.0.

Là c'est pareil, il faut changer les choses, mais soi-disant que l'on ne peut pas le faire comme ça, faut d'abords faire des tests, etc ... Ca fait plus de 2 ans que l'on en parle, c'est toujours pas planifié.

Je ne voie pas trop quel genre de tests faut-il faire.
Pour rester compatible avec tous les clients, il faut faire le choix d'un développement basique, sans spécificité.
Peut-être que le Dialect 1 répond à ce besoin.

Dommage qu'il n'y a pas une documentation venant détailler les règles du jeu.

@+

[SergioMaster]

Bonjour,

je déconseille le charset NONE, quant au COLLATE NONE ça ne sert AMHA à rien
pour ce qui est du Dialect pareil je conseille le 3 le 1 réduit fortement certaines choses (entre autres les dates ne peuvent être que des TIMESTAMP.
Je me trimballe une base "historique" (commencée en Interbase 5.4) en CHARSET NONE DIALECT1 , c'est frustrant !

Mais une migration n'est pas aussi simple que le dire , surtout si l'on a des colonnes COMPUTED BY ou pire des Blobs.
Il faut 1- extraire les métadonnées pour recréer les tables
2- ne pas créer les triggers et index et à fortiori les procédures avant d'avoir transférer les données
le hic c'est que pour profiter pleinement du dialect 3 il est bon de reprendre certaines tables choix entre DATE et TIMESTAMP (tant qu'à faire autant faire bien)
Il est dommage que FBCopy ne soit pas un GUI pour pouvoir bien transférer les données (ah si j'avais un stagiaire sous la main je saurais quoi lui proposer comme programme de stage )

[Artemus24]

Salut SergioMaster.

Mais une migration n'est pas aussi simple que le dire

Une migration, c'est aussi une conversion des données d'un ancien type vers un nouveau.
Le changement des règles de gestions, voire aussi une refonte du modèle conceptuel des données.
Et résoudre au passage, quelques problèmes qui empoisonnent les DBA.

2- ne pas créer les triggers et index et à fortiori les procédures avant d'avoir transférer les données

Je vais toujours la distinction entre migration des données et migrations des traitements.
A ce niveau de distinction, un déclencheur, c'est un traitement.

ah si j'avais un stagiaire sous la main je saurais quoi lui proposer comme programme de stage

Tu proposes de refaire en totalité l'outil "gbak" ou d'ajouter des patchs ?

@+

[SergioMaster]

Bonjour,

Tu proposes de refaire en totalité l'outil "gbak" ou d'ajouter des patchs ?

non il ne s'agit pas de GBAK mais plutôt de FBCopy ou IBPump (en rajoutant les connexions à d'autres SGBD) avec sélection et correspondance de champs (pour répondre aux changements de nom ou de types) tout ceci de manière graphique. J'avais déjà fait un outil de ce genre (moins perfectionné) pour un dépannage, vers la fin du siècle dernier , mais je ne l'ai pas gardé. Au début des vacances, encore plein de courage, j'y songeai mais, l'eau était claire et ma motivation s'est reportée vers la chasse sous marine et mon tableau de chasse

[cantador]

non il ne s'agit pas de GBAK mais plutôt de FBCopy ou IBPump (en rajoutant les connexions à d'autres SGBD) avec sélection et
correspondance de champs (pour répondre aux changements de nom ou de types) tout ceci de manière graphique.

ça serait super !