Discussion :

[Hecatonchar]

Bonjour à toutes et tous,

J'ai rencontré le souci suivant lors de l'export puis import d'une table via SQL Developer. Suite à l'exposé du problème j'expliquerais l'hypothèse que j'ai pu formuler quant au "pourquoi?". Si à tout hasard vous aviez un meilleur "pourquoi?" voire un "comment?" vous feriez de moi le plus heureux des newbies sur ce forum

J'ai donc une table que je souhaite exporter depuis Oracle pour l'importer sur une autre connexion (Oracle également). J'ai essayé avec plusieurs formats d'export mais mettons que je décharge ma table depuis la connexion A en .tsv, fichiers distincts.

Sous la connexion B je lance le script de création de table, une fois celle-ci créée je clique-droit dessus>Import data. Je vérifie les définitions des champs, leurs correspondances, tout semble OK, je lance la manip' et horreur: "Erreur: ORA-12899 valeur trop grande pour la colonne MON_SCHEMA.MA_TABLE.MA_COLONNE (réelle : 31, maximum : 30)".

Cette erreur se produit sur plusieurs champs (mais pas tous) de types variés (VARCHAR, DATE, NUMBER). En poursuivant la requête malgré les erreurs je constate que la différence de taille de chaîne (=réelle-maximum) n'excède pas les 5 ou 6 caractères.

Je me dis que le logiciel fait une estimation des tailles de champs sur les premiers enregistrements, je fais donc un MAX(LENGTH()) sur tous mes champs: les valeurs renvoyées correspondent bien aux définitions de champs fournies par Oracle lors du déchargement.

En y pensant en l'air je me dis qu'il est possible que certains caractères "prennent plus de place" dans le format d'export (ajout de caractères d'échappement pour les éventuels séparateurs contenus dans les champs, transformation des caractères spéciaux sous une forme moins ambigüe mais plus longue...).
Toujours est-il que de ne pas retomber sur mes pieds d'Oracle à Oracle me rend un peu chagrin (si Oracle modifie les données en export, pourquoi ne fait-il pas l'opération inverse lors de l'import?) et que surtout, pendant ce temps là, ben il n'y a rien qui est fait ^^.

Merci par avance pour votre attention et éventuels éléments de réponses.
Merci aussi à la communauté qui, sans le savoir, m'a souvent tiré de l'ornière auparavant.

Bien à vous,
H.

[Waldar]

Vous avez probablement vu juste.
Quel est le résultat de cette requête sur les deux environnements ?

Code :

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

1
2
3
select *
  from sys.nls_database_parameters
 where parameter in ('NLS_LENGTH_SEMANTICS', 'NLS_CHARACTERSET')

[Hecatonchar]

Bonjour Waldar,

Merci beaucoup pour votre réaction

Dans l'environnement source (A) la requête renvoie:

PARAMETER	   VALUE
NLS_CHARACTERSET	AL32UTF8
NLS_LENGTH_SEMANTICS	BYTE

Dans l'environnement cible (B):

PARAMETER	   VALUE
NLS_CHARACTERSET	AL32UTF8
NLS_LENGTH_SEMANTICS	BYTE

(désolé si les sorties ne sont pas très lisibles, premier post de ma part et j'ignore donc encore beaucoup des habitudes et usages)

J'espère que cela pourra vous éclairer.
Je suppose cependant que la solution aurait été plus simple si la requête avait renvoyé des valeurs différentes dans chaque environnement? ~^

Cordialement,
H.

[Waldar]

Pas nécessairement, déjà vous êtes sur un character_set multibytes ça permet donc de poursuivre dans cette voie.
Je vous ai fait regarder le paramètre par défaut, mais celui-ci est contournable dans le script de création des tables.

Qu'il faut donc regarder :

Code :

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

1
2
3
4
5
select owner, table_name, column_name, char_used, data_type
  from all_tab_columns
 where owner      = <nom_user>
   and table_name = <nom_table>
   and data_type like '%CHAR_';

[Hecatonchar]

Dans l'environnement source:

USERNAME	TABLE_SOURCE	AUTCOMINF	B	VARCHAR2
USERNAME	TABLE_SOURCE	AUTCOMEP	C	VARCHAR2
USERNAME	TABLE_SOURCE	AUTBASEP	C	VARCHAR2
USERNAME	TABLE_SOURCE	AUTBASINF	B	VARCHAR2
USERNAME	TABLE_SOURCE	GENRE		C	VARCHAR2
USERNAME	TABLE_SOURCE	CODTAXIN	B	VARCHAR2
USERNAME	TABLE_SOURCE	FAMILLE		B	VARCHAR2
USERNAME	TABLE_SOURCE	ESPECE		C	VARCHAR2
USERNAME	TABLE_SOURCE	NOMINFSP	C	VARCHAR2
USERNAME	TABLE_SOURCE	PARTS		B	VARCHAR2
USERNAME	TABLE_SOURCE	SECTEUR		B	VARCHAR2
USERNAME	TABLE_SOURCE	LOC		C	VARCHAR2
USERNAME	TABLE_SOURCE	COD_BOT_TDWG	B	VARCHAR2
USERNAME	TABLE_SOURCE	COD_UB_TDWG	B	VARCHAR2
USERNAME	TABLE_SOURCE	NOMLOC		C	VARCHAR2
USERNAME	TABLE_SOURCE	PRES_XY		C	VARCHAR2
USERNAME	TABLE_SOURCE	P_NUM_REC	C	VARCHAR2
USERNAME	TABLE_SOURCE	UNIT_ALT	B	VARCHAR2
USERNAME	TABLE_SOURCE	UNIT_POLINF	C	VARCHAR2
USERNAME	TABLE_SOURCE	UNIT_POLSUP	B	VARCHAR2
USERNAME	TABLE_SOURCE	CONTINENT	C	VARCHAR2
USERNAME	TABLE_SOURCE	DATCOMPL	C	VARCHAR2
USERNAME	TABLE_SOURCE	PAY		B	VARCHAR2
USERNAME	TABLE_SOURCE	NOT		C	VARCHAR2
USERNAME	TABLE_SOURCE	COD_ISO		B	VARCHAR2
USERNAME	TABLE_SOURCE	DESC		B	VARCHAR2

Et dans l'environnement cible:

USERNAME	TABLE_CIBLE	AUTCOMINF	B	VARCHAR2
USERNAME	TABLE_CIBLE	AUTCOMEP	C	VARCHAR2
USERNAME	TABLE_CIBLE	AUTBASEP	C	VARCHAR2
USERNAME	TABLE_CIBLE	AUTBASINF	B	VARCHAR2
USERNAME	TABLE_CIBLE	CODTAXIN	B	VARCHAR2
USERNAME	TABLE_CIBLE	FAMILLE		B	VARCHAR2
USERNAME	TABLE_CIBLE	ESPECE		C	VARCHAR2
USERNAME	TABLE_CIBLE	GENRE		C	VARCHAR2
USERNAME	TABLE_CIBLE	NOMINFSP	C	VARCHAR2
USERNAME	TABLE_CIBLE	PARTS		B	VARCHAR2
USERNAME	TABLE_CIBLE	SECTEUR		B	VARCHAR2
USERNAME	TABLE_CIBLE	LOC		C	VARCHAR2
USERNAME	TABLE_CIBLE	COD_BOT_TDWG	B	VARCHAR2
USERNAME	TABLE_CIBLE	COD_UB_TDWG	B	VARCHAR2
USERNAME	TABLE_CIBLE	NOMLOC		C	VARCHAR2
USERNAME	TABLE_CIBLE	PRES_XY		C	VARCHAR2
USERNAME	TABLE_CIBLE	P_NUM_REC	C	VARCHAR2
USERNAME	TABLE_CIBLE	UNIT_ALT	B	VARCHAR2
USERNAME	TABLE_CIBLE	UNIT_POLINF	C	VARCHAR2
USERNAME	TABLE_CIBLE	UNIT_POLSUP	B	VARCHAR2
USERNAME	TABLE_CIBLE	CONTINENT	C	VARCHAR2
USERNAME	TABLE_CIBLE	DAT_COMPL	C	VARCHAR2
USERNAME	TABLE_CIBLE	PAY		B	VARCHAR2
USERNAME	TABLE_CIBLE	NOT		C	VARCHAR2
USERNAME	TABLE_CIBLE	COD_ISO		B	VARCHAR2
USERNAME	TABLE_CIBLE	DESC		B	VARCHAR2

Pour information j'ai réussi à importer la table en passant tous les champs en VARCHAR(2000). Je débute en BDD mais ça ne ressemble pas à une "bonne pratique". De plus impossible de réduire les champs à posteriori (UPDATE d'une table à l'autre au sein du même environnement).

Si cela peut aider également, parmi les "valeurs" qui "dépassent", il y a des NULL ce qui me semble aberrant mais fera peut être du sens dans ce cas précis.

Encore merci pour votre aide,
H.


P.S. Je n'aurais plus accès aux environnements d'ici demain matin (et donc hélàs difficile de les interroger d'ici là).

[Waldar]

J'ai oublié de mettre les longueurs dans ma requête, enfin j'imagine que ce sont les mêmes.

Effectivement, tout mettre en varchar2(2000), ce n'est pas ce qu'il y a de mieux, on essaie d'ajuster.