/* Deux ou trois rappels sur le fragment requetes de SQL... */

La casse n'est pas signifiante en SQL (mais bien sur si dans les chaines de 
caracteres). <br>

Selectionner valeur indefinie : where a is null (et pas a=null : testez) <br>
Selectionner sur un prefixe : ... where a like 'T%' : a commence par T <br>

<p>
Remarques sur les types char(10) et varchar2(10). 
<br>
Soit a inserer la chaine 'toto' dans une colonne nom de type char(6) :
Oracle ajoute sans prevenir 2 espaces pour arriver a 6. 
C'est donc 'toto  ' qui est stockee et non 'toto'. 
Comme ces espaces ont ete ajoutes artificiellement par Oracle, lors d'une 
requete where nom='toto', Oracle les ignore dans la base, et il ramene bien
les lignes de  nom 'toto'.
En resume, l'utilisateur a entre 'toto' et il voit 'toto'.

<br>
<br>
Soit a inserer la chaine 'toto' dans une colonne nom de type varchar2(6) :
Oracle n'ajoute rien, c'est le but de varchar. 
C'est donc bien 'toto' qui est stockee.
Mais supposons maintenant qu'on stocke 'toto  '. 
Ces espaces ne sont pas artificiels puisque c'est l'utilisateur qui les a 
choisis.
En consequence, lors d'une requete where nom='toto', Oracle cherche 'toto' et
ne trouve pas 'toto  '...
Il faut donc chercher avec like.

Conclusion.
La semantique du where depend de celle du = (raisonnable).
Il y a donc des coercions implicites, comme en Java (ou C), auxquelles 
le programmeur est confronte malgre lui meme dans les requetes triviales...
Il faut donc alle voir dans la definition de la base le type des colonnes !
Ce qui est encore assez raisonnable...





