Syntaxe varchar(20) et varchar2(20 char)

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:

---

1 2 3

CHARACTER VARYING(14), CHAR VARYING(14), VARCHAR(14)

---

oracle lui utilise

Code:

---

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:

---

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:

---

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

Non.

Citation:

---

Envoyé par sekaijin

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.

Citation:

---

Envoyé par sekaijin

...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.

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

Citation:

---

Envoyé par sekaijin

...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.

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

Citation:

---

Il n'y en a pas

---

:aie:

Citation:

---

Envoyé par Rei Ichido

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

---

:ccool:

merci je vais voir comment avoir ce paramètre par défaut à char pour mes users

A+JYT

Citation:

---

Envoyé par Rei Ichido

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 ! :aie:
Sous un compte lambda, ça fonctionne effectivement sans souci...

merci pour l'info
A+JYT

Citation:

---

Envoyé par Pomalaix

...
...
Ca m'apprendra à tester sous SYS ! :aie:
...

---

Citation:

---

- Never ever use SYS (or SYSDBA) but for maintenance purpose (startup, shutdown, backup, recover)
- SYS/SYSDBA is special
- SYS/SYSDBA is Oracle proprietary (try to open a SR/TAR starting with "i did that with SYS/SYSDBA" and you'll see the immediate answer)
- SYS/SYSDBA does not act like any other user
- When you use SYS/SYSDBA Oracle deactivates some code path and activates others
- Whatever you do with SYS/SYSDBA will neither validate nor invalidate the same thing with any other user.

NEVER EVER use SYS/SYSDBA for anything that can be done by another user.
Use SYS/SYSDBA ONLY for something that can't be done by someone else.

--------------------------------------------------------------------------------

---

SYS/SYSDBA is special

finalement je suis passé par le build du projet.

le source contient deux fichier
session-oracle.sql (qui contient alter session pour fixer le NLS_LENGTH_SEMANTICS)
et create.sql

au build je produit deux fichiers
create-oracle.sql (concaténation de session-oracle.sql et create.sql)
et create-ansi.sql (create.sql seul)

Ainsi j'ai un seul source à maintenir et je produit le script create pour oracle ou derby.

Merci à vous.
A+JYT