Discussion :

[sekaijin]

Bonjour.

je suis confronté à un petit pb de compatibilité entre les bases de données.

les développeurs utilisent sur leur poste la base Derby (ce qui permet d'avoir des tests unitaire indépendant de toute infrascruture)

et les plateforme de d'intégration recette et production utilisent Oracle
nous avons de très nombreux petits projets qui ont tous au moins 1 script sql associé.
nous aimerions éviter d'avoir à écrire plusieurs fois ces scripts (1pour derby 1 pour oracle)

le problème vient de varchar

derby supporte SQL92T soit donc les syntaxe

Code :

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

1
2
3
CHARACTER VARYING(14),
CHAR VARYING(14),
VARCHAR(14)

oracle lui utilise

Code :

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

1
2
3
CHARACTER VARYING(14 CHAR),
CHAR VARYING(14 CHAR),
VARCHAR2(14 CHAR)

juste pour ce détail il m'est pour le moment impossible d'avoir un script unique pour la création des tables. il me faut systématiquement une version oracle et une version derby.

si j'utilise la syntaxe de derby sur oracle j'obtiens

Code :

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

1
2
3
CHARACTER VARYING(14 BYTE),
CHAR VARYING(14 BYTE),
VARCHAR2(14 BYTE)

Or étant en utf-8 cela ne corresponds pas à mon besoin. en effet "éosine aqueuse" par exemple fait 14 chars mais 15 bytes.

existe-t-il un moyen de paramétrer mon schémas oracle pour que

Code :

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

1
2
3
CHARACTER VARYING(14),
CHAR VARYING(14),
VARCHAR(14)

crée par défaut des chars et non des bytes ?

Merci
A+JYT

[mnitu]

Non.

[skuatamad]

les développeurs utilisent sur leur poste la base Derby (ce qui permet d'avoir des tests unitaire indépendant de toute infrascruture)

Pourquoi ne pas utiliser Oracle Express Edition qui est gratuit et facilement installable sur les postes des développeurs.

[Pomalaix]

...les développeurs utilisent sur leur poste la base Derby (ce qui permet d'avoir des tests unitaire indépendant de toute infrascruture)

et les plateforme de d'intégration recette et production utilisent Oracle...

Une telle organisation n'a aucune chance de fonctionner !

Les différents SGBD diffèrent notamment par les types de données qu'ils supportent (par exemple CURRENCY chez l'un, pas chez l'autre), par leurs fonctions natives, par leurs mécanismes transactionnels, par leur degré de respect des normes SQL...

Si la prod fonctionne avec le SGBD X, le développement doit se faire sur ce même SGBD.
Comme le suggère skuatamad, vous pouvez utiliser Oracle Express qui est 100% gratuit, ou Oracle Personal Edition, qui est très accessible (de l'ordre de 150 € par poste).

Croire que les SGBD sont interchangeables (et qu'on peut bricoler sans un minimum de formation) est un leurre aux conséquences très graves.

[sekaijin]

mes besoins dans chaque projet sont particulièrement léger

integer et varchar éventuellement char.

j'imagine assez mal un serveur d'intégration continue qui sur des centaine de petits projets vas à la volé installer un serveur oracle créer des user et des schémas passer des script pour enfin pouvoir lancer des test junits qui font un pauvre sélect sur une table à trois colonne.

croire que mettre l'artillerie lourde partout est une solution est pour moi tout aussi fou que de penser que les SGBD peuvent être 100% interchangeable.

ma question ne porte que sur un point très précis car c'est le seul et unique point de blocage pour avoir un script qui s’exécute sur Derby et sur Oracle.

Au pire on fera un utilitaire qui remet en Ansi SQL92 les scripts avant de les exécuter. Mais s'il y a une solution avec du paramétrage ce sera tout de même mieux.

A+JYT

[mnitu]

...Mais s'il y a une solution avec du paramétrage ce sera tout de même mieux.

A+JYT

Il n'y en a pas.

[Rei Ichido]

Il faut positionner le paramètre NLS_LENGTH_SEMANTICS à CHAR et non BYTE.

[mnitu]

Il n'y en a pas

Il faut positionner le paramètre NLS_LENGTH_SEMANTICS à CHAR et non BYTE.

[Pomalaix]

Il faut positionner le paramètre NLS_LENGTH_SEMANTICS à CHAR et non BYTE.

J'avais immédiatement pensé à cette solution ce matin en lisant la question, et je me suis dit que j'allais l'accompagner d'une petite démonstration.
Le souci, c'est que cette modification n'avait pas l'effet attendu.

La doc vient de m'apprendre que les sessions SYS ne prennent pas en compte le paramètre NLS_LENGTH_SEMANTICS, et fonctionnent en mode BYTE sauf si on indique explicitement CHAR à la création de la colonne.

Ca m'apprendra à tester sous SYS !
Sous un compte lambda, ça fonctionne effectivement sans souci...