Transformer une base de données CHARACTER SET NONE, SQL DIALECT 1
par
, 22/10/2024 à 16h02 (1411 Affichages)
J'utilise Firebird depuis des années, en fait pratiquement depuis sa parution, et ce, à la place d'Interbase.
J'ai commencé avec Interbase 5, novice à l'époque ma base de données avait été créée avec le set de caractères CHARACTER SET NONE et en DIALECT SQL 1, rien n'indiquait à l'époque qu''il était fortement conseillé d'utiliser des CHARACTER SET différent de celui par défaut (le fameux NONE) quant au SQL DIALECT soit j'ai mal cherché dans la documentation que j'ai encore, soit il n'existait que le 1 (et peut-être le 2).
La base de données ayant été ensuite mise en production, autant par fénéantise que par méconnaissance, elle est restée telle quelle depuis lors.
La migration d'interbase vers Firebird 1.5, 2 puis 2.5 s'étant passé sans difficultés (par l'intermédaire d'un backup portable de l'ancienne version puis d'un restore avec la nouvelle), à part quelques frustations à cause du SQL DIALECT entre autres avec les fonctions de Date.
Passer la base de données telle quelle vers les nouvelles versions Firebird 3, 4 ou 5 avec cette même technique, c'est possible, mais j'ai voulu profiter de cette occasion pour opérer ces changements.
Changer de CHARACTER SET
Sous Windows, lancez dans une console (powershell ou cmd) le programme ISQL que l'on peut trouver dans la racine de l'installation de Firebird
Envoyé par PowerShell
AMHA Changer de set de caractère devra forcément passer par l'étape WIN1252
Changer de SQL DIALECT
Sous Windows, lancez dans une console (powershell ou cmd) le programme gfix que l'on peut trouver dans la racine de l'installation de Firebird
Pour vous assurer que tout est OK un retour dans ISQL et la commande SHOW SQL DIALECT; devrait vous rassurer.PS ... >
CD "C:\program files\firebird\firebird_4_0"
PS C:\program files\firebird\firebird_4_0> ./gfix -sql_dialect 3 <nom de la base à transformer entre " " ou nom de l'alias> -user sysdba -password masterkey
Bien évidemment il faudra ensuite faire la chasse aux mots clés, abandonner les UDFs et prendre en compte les nouveaux types de données (en particulier l'utilisation des CURRENT_TIMESTAMP et CURRENT_TIME dans les procedures à remplacer par LOCALTIMESTAMP et LOCALTIME) qui sont elles rapportées dans les guides de migration chapitre 2.
Notes :
- Par "abandon des UDF" je veux souligner que l'utilisation des UDF est désormais considéré comme obsolète (chapitre 2.2).
- Les littéraux de dates ou heure ('NOW','TODAY',...) sont désormais dépréciés et peuvent produire des résultats inattendus.
Cependant, mes dernières interventions ou contacts via le forum, me font penser que beaucoup sont dans le cas tel que décrit, c'est pour ceux-là que j'ai voulu vous faire part de ces deux petites astuces![]()