ORA-12899: value too large for column
Description
L’erreur « ORA-12899: value too large for column » peut être constatée dans les logs des Intranet Servers Planisware lors d’une transaction d’enregistrement en Base de Données (BDD).
Exemple : ORA-12899: value too large for column \ »BASE_DEV2\ ».\ »NETWORK\ ».\ »NAME\ »(actual: 84, maximum: 80)
Ici on constate que l’on souhaite enregistrer le nom d’un sous-projet d’une longueur de 84 (caractères ou bytes en fonction du type d’encodage du champ « NAME » en BDD). Or ce champ a une longueur maximale de 80 en BDD.
Cause
Il y a une incompatibilité entre la longueur du champ à enregistrer et la taille maximale du champ admissible dans la BDD. Ce problème peut-être rencontré si la BDD est encodée en UTF8. En effet, en UTF8 les caractères accentués ou spéciaux sont encodés sur un plus grand nombre de bytes qu’en encodage classique ISO.
En général, on constate ce genre d’erreur pour des champs de type chaine de caractères dont l’encodage en BDD est de type BYTE et la BDD paramétrée en UTF8 ou AL32UTF8 : dans ce cas la taille maximum autorisée en base sera de n BYTE alors que P5 va autoriser la saisie de n caractères (codés sur m bytes avec m ≥ n).
Résolution
Il s’agit de remettre en cohérence le modèle physique de données avec le type d’encodage de la BDD. C’est à dire faire en sorte que les champs de type « chaine de caractères » du schéma P5 soient tous de type CHAR et non pas BYTE. En effet dans ce cas le SGBD prévoit l’espace nécessaire à l’encodage de n caractères et pas de seulement n bytes.
1) La modification des champs concernés directement dans la BDD n’est pas recommandée car :
→ Elle est longue (en générale la quasi totalité des champs « chaine de caractères » sont à migrer.
→ Elle est plus risqué car l’intervention est réalisée directement en BDD.
2) La migration globale de la BDD par export / import
→ Il s’agit de réaliser un dpx de la BDD P5 puis de le réimporter dans une BDD où le « NLS_LENGTH_SEMANTICS » (dans le cas d’Oracle) est positionné à « CHAR ».
→ L’export / import via les outils standard du SGBD (ex. sous Oracle exp/imp, expdp/impdp …) est également possible en s’assurant que la BDD cible a bien un « NLS_LENGTH_SEMANTICS » positionné à « CHAR » (dans le cas d’Oracle) et que les options d’import permettent de préciser le type d’encodage par défaut pour ne pas conserver l’encodage des champs en BYTE.