Les formats d’encodage des bases de données évoluent pour prendre en compte des besoins de plus en plus étendus. A titre d’exemple, la prise en compte de caractères nouveaux à stocker en base où une application multilingue peuvent nécessiter d’utiliser l’encodage UTF8. La principale difficulté vient du fait que l’encodage en UTF8 prend plus de place en base (les caractères sont encodés sur un nombre plus important de bits).
Dans ce cas 2 situations peuvent se présenter :
→ L’application P5 est une nouvelle application : dans ce cas on crée une base directement en UTF8. Tous les objets (données et paramétrage) du modèle de données Planisware seront directement encodés en UTF8.
→ L’application P5 est issue de la récupération d’une application existante que l’on souhaite migrer. Dans ce second cas, il sera préférable d’exporter l’intégralité de la base d’origine (encodée en ISO par exemple) par archive dpx, puis d’importer ce dpx dans la base cible (encodée UTF8) via le client lourd P5.
Le schéma suivant résume la procédure de migration :
Cette façon de procéder évite d’avoir à gérer manuellement la conversion d’encodage directement dans le SGBD. Par exemple, sous Oracle, il aurait été possible de faire un export de la base d’origine ISO, puis un import dans une nouvelle base encodée en UTF8. En effet Oracle gère la conversion de caractères. Cependant certains champs dont les tailles sont définis « en bits » et pas « en nombre de caractères » dans la base d’origine vont poser problème car Oracle pourra manquer de place lors de l’import du contenu de ces champs.
C’est la raison pour laquelle il est préférable de passer par un dump applicatif (dpx) plutôt que de devoir gérer des redimensionnements de champ en base de données.
