[Oracle] Enlever le case sensitive???

Salut,
j'aimerai enlever le case sensitive d'oracle, est ce possible?

voici mon contexte:
J'utilise une application (Metastorm E-work), celle-ci importe une liste de user depuis notre annuaire LDAP.
Mon probleme est que les user sont écrit un peu n'importe comment:
User / USER / user ...

Du coup lorsque je vais communiquer les logins, certains seront en maj, d'otre en min d'autres avec la premiere en maj... bref, vous voyez le soucy.

La solution est d'enlever le case sensitive d'oracle...
Enfin si vs voyez d'autres solutions miracle, n'hésitez pas! :)

MERCI D'AVANCE

Bonjour,

Pour ma part j'aurais inséré tous ces users en majuscules ou en minuscules, comme ça c'est réglé et normé ! :)

Bien sûr, il est impossible d'annuler le case sensitive d'Oracle...

Mais si je ne m'abuse, même plusieurs utilisateurs avec une casse différente (Test, tEst, TEST, test) auront TOUS le même schéma!

Euh... Oracle est case INsensitive !

que je fasse

Code:

---

connect SCOTT/TIGER

---

ou

Code:

---

connect Scott/Tiger

---

ou

Code:

---

connect scott/tigger

---

La connection se fait bien dans tous les cas... 8O

Citation:

---

même plusieurs utilisateurs avec une casse différente (Test, tEst, TEST, test) auront TOUS le même schéma!

---

Attention, j'importe des user pour l'application e-work pas oracle!

mon prb c'est que je n'ai pas la main pour faire mon import depuis LDAP. il créer automatiquement des enregistrements dans la base des users de l'appli...

Citation:

---

il est impossible d'annuler le case sensitive d'Oracle

---

J'comprends... mais ca m'aurai bien aidé! :)

Citation:

---

Envoyé par LeoAnderson

Euh... Oracle est case INsensitive !

que je fasse

Code:

---

connect SCOTT/TIGER

---

ou

Code:

---

connect Scott/Tiger

---

ou

Code:

---

connect scott/tigger

---

La connection se fait bien dans tous les cas...

---

:oops: C'était ce que je voulais dire, mais je me suis mal exprimé...

merci pour votre aide, mais moi aussi j'me suis mal exprimé.

J'import des enregistrements dans une table.
Le résultat est le suivant:

lorsque je fait: SELECT * FROM EUSER WHERE eusername='User';

Ca n'est pas la meme chose que: SELECT * FROM EUSER WHERE eusername='USER';

dsl pour mes prb de clareté :p

Code:

---

SELECT upper(eusername), ... FROM EUSER WHERE EUSERNAME=UPPER('user');

---

[EDIT]
Te prendra tous les utilisateurs (uSer, User, USER, etc, etc), car upper('uSer') donne USER, et where ... = upper('user') donne aussi USER...

Upper met tous les caractères en majuscule...
[/EDIT]

Je pense qu'un trigger before_insert sur la table euser résoudra tes problèmes.
Avant insertion de la colonne, tu la positionnes en upper ou en lower

Citation:

---

Envoyé par osmoze

j'aimerai enlever le case sensitive d'oracle, est ce possible?

---

Je ne comprends pas clairement vos contraintes, mais pour répondre bêtement à la question, c'est tout à fait possible :

ALTER SESSION SET NLS_COMP=ANSI;
ALTER SESSION SET NLS_SORT=GENERIC_BASELETTER;

Ainsi, User, uSer, USER, tout ça c'est du pareil au même.

MERCI a tous pour votre aide.
Je vais essayer ttes ces idées tres interessantes.

bonne continuation a tous...

Bonjour Pomalaix,

Citation:

---

Envoyé par Pomalaix

[Je ne comprends pas clairement vos contraintes, mais pour répondre bêtement à la question, c'est tout à fait possible :

ALTER SESSION SET NLS_COMP=ANSI;
ALTER SESSION SET NLS_SORT=GENERIC_BASELETTER;

Ainsi, User, uSer, USER, tout ça c'est du pareil au même.

---

Je ne connaissais pas ces options, j'ai tenté un petit test :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

SQL> ed Wrote file afiedt.buf   1* create table TEST as select initCap(object_name) nom from all_objects SQL> /   Table created.   SQL> select * from TEST where rownum < 10;   NOM ------------------------------ Dual Dual System_Privilege_Map System_Privilege_Map Table_Privilege_Map Table_Privilege_Map Stmt_Audit_Option_Map Stmt_Audit_Option_Map Standard   9 rows selected.   SQL> select * from TEST where nom = 'dUaL';   no rows selected   SQL> ALTER SESSION SET NLS_COMP=ANSI;   Session altered.   SQL> ALTER SESSION SET NLS_SORT=GENERIC_BASELETTER;   Session altered.   SQL> SQL> select * from TEST where nom = 'dUaL';   NOM ------------------------------ Dual Dual System_Privilege_Map System_Privilege_Map Table_Privilege_Map Table_Privilege_Map Stmt_Audit_Option_Map Stmt_Audit_Option_Map Standard V$Dlm_Misc V$Dlm_Latch V$Dlm_Convert_Local ...

---

Ca n'a pas l'air de fonctionner ?

Laly.

D'après Metalink (Cf. Note:109118.1)

Citation:

---

GENERIC_BASELETTER LINGUISTIC DEFINITION ---------------------------------------- A new linguistic definition, also known as "sort", has been added to Oracle. The name of this definition is GENERIC_BASELETTER. 'Base Letters' are Latin characters with all accents stripped away. This definition was added to Oracle in version 8.1.6 but you can only use it to it's full extent since version 9.2.

---

Ca ne fonctionne donc qu'à partir d'Oracle 9iR2, quelqu'un peut confirmer ?

En tout cas je retiens le "truc".


Merci,

Laly.

Citation:

---

Envoyé par lalystar

Ca ne fonctionne donc qu'à partir d'Oracle 9iR2, quelqu'un peut confirmer ?

---

Ca je l'ignore...

Mais l'effet de la chose n'est pas d'influer sur le stockage (les majuscules ou minuscules sont respectées), ni sur l'affichage (là encore, si tu rentres "TotO", tu retrouves "TotO"), mais sur la sélectivité.

Je m'explique :

Code:

---

1 2 3 4

CREATE TABLE TEST (a VARCHAR2(10)); INSERT INTO TEST VALUES('toto'); INSERT INTO TEST VALUES('TOTO'); INSERT INTO TEST VALUES('TotO');

---

-- en temps normal

Code:

---

1 2 3 4 5

SELECT * FROM TEST WHERE a='TOTO';   A ---------- TOTO

---

-- avec la fameuse manip

Code:

---

1 2 3 4 5 6 7 8 9 10

ALTER SESSION SET NLS_COMP=ANSI; ALTER SESSION SET NLS_SORT=GENERIC_BASELETTER;   SELECT * FROM TEST WHERE a='TOTO';   A ---------- toto TOTO TotO

---

Tu vois le truc ? :wink:

Je ne suis pas sûr d'avoir compris : dans mon exemple, je cherche les lignes qui sont similaires alors qu'aucune n'est exactement la même.
Dans ton exemple, tu cherches les lignes similaires alors qu'il y en une qui est exactement la même.

J'en déduis, que si la requête renvoie une ligne, elle renvoie aussi les formes "équivalentes" ?

En tout cas, j'ai l'impression que ces commandes ont de dangereux effets secondaires :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

1* select object_name from all_objects where rownum < 10 SQL> /   OBJECT_NAME ------------------------------ DUAL DUAL SYSTEM_PRIVILEGE_MAP SYSTEM_PRIVILEGE_MAP TABLE_PRIVILEGE_MAP TABLE_PRIVILEGE_MAP STMT_AUDIT_OPTION_MAP STMT_AUDIT_OPTION_MAP STANDARD   9 rows selected.   SQL> ALTER SESSION SET NLS_COMP=ANSI;   Session altered.   SQL> ALTER SESSION SET NLS_SORT=GENERIC_BASELETTER;   Session altered.   SQL> select object_name from all_objects where rownum < 10;   no rows selected

---

Ca me parait très mystérieux tout cas (je suis en 8.1.7.4)...


Laly.

Citation:

---

Envoyé par lalystar

J'en déduis, que si la requête renvoie une ligne, elle renvoie aussi les formes "équivalentes" ?

---

Ca n'a pas l'air d'être ca (Cf. http://download-west.oracle.com/docs...h4.htm#1010707).

Citation:

---

Performing a Generic Base Letter Search
You can perform a search that ignores case and diacritics. Enter the following statements:

ALTER SESSION SET NLS_COMP=ANSI;
ALTER SESSION SET NLS_SORT=GENERIC_BASELETTER;


Then enter a statement similar to the following:

SELECT * FROM emp WHERE ename='miller';


This statement can now return names that include the following:

Miller
MILLER
Millér


Note that this is not a linguistic search; that is, it is not based on a specific language. It uses the base letters only

---

Je n'arrive décidémment pas à voir la nuance !


Laly.

Citation:

---

Envoyé par lalystar

Je n'arrive décidémment pas à voir la nuance !

---

Ce qui se comprend, vu que ça déconne complètement chez toi !

En 9iR2 il n'y a pas d'effets secondaires sur le ROWNUM.

Sinon, pour le formuler autrement, avec ce paramétrage,

Code:

---

1 2	SELECT ... FROM table WHERE colonne=x

---

est traité comme

Code:

---

SELECT ... FROM table WHERE upper(colonne)=upper(x)

---

(c'est même plus puissant que ça, puisque même les accents sont ignorés)

Citation:

---

Envoyé par Pomalaix

Sinon, pour le formuler autrement, avec ce paramétrage,

Code:

---

1 2	SELECT ... FROM table WHERE colonne=x

---

est traité comme

Code:

---

SELECT ... FROM table WHERE upper(colonne)=upper(x)

---

(c'est même plus puissant que ça, puisque même les accents sont ignorés)

---

Si c'est le cas, c'est très utile.

Je ferais le test chez moi (10g) pour vérifier. Je voulais savoir ce qu'il en était si on faisait la recherche sur une colonne indexée. Mais vu la seconde requête, aucun index ne pourra être utilisé.


Merci,

Laly.

pour ma part, j'vais travailler comme ca:

Citation:

---

SELECT ... FROM table WHERE upper(colonne)=upper(x)

---

ca fonctionne et ca me convient :) (dsl pour la gene occasionnée)

Citation:

---

Envoyé par osmoze

dsl pour la gene occasionnée

---

Je ne pense pas que tu as créer une gêne, mais plutôt un débat fort interressant et instructif :wink:

Bonjour,
J'ai ouvert un topic sur un pb de select qui nous a fait rebondir sur un problème d'accent : topic

Mais voilà j'ai essayé la solution Alter et mes code bizzard A (accentué) ne sort pas dans mon select (voir l'autre post pour comprendre).

Donc cet Alter, ne semble pas fonctionner pour les majuscules accentuées.

Sans être sur, il me semble que ça ne marche pas avec LIKE pour les accents.