ASP

Construire une requête SQL

Construire une requête SQL - Comment isoler les guillemets dans une requête.

Une base de données n’a pas vraiment de problème avec les guillemets et les apostrophes. Et c’est tout à fait faux de dire que le langage ou les requêtes SQL n’acceptent pas les apostrophes. L’interprétation d’une chaîne de caractères qui contient des guillemets n’est pas non plus un problème.

Qu’est-ce qu’il y a de spéciale avec une requête SQL c’est qu’elle est elle-même une chaîne de caractère. Vous savez tous qu’une chaîne de caractère est généralement construite à l’aide de guillemets ou d’apostrophe pour délimiter le début et la fin de la chaîne. Alors quand il est question de chaîne à l’intérieur d’une autre chaîne il y a nécessairement une méthode à suivre.

La méthode n’a d’ailleurs rien à voir avec les requêtes SQL, mais bien avec le langage qui manipule une requête SQL. En outre, chaque langage à sa propre façon de manipuler les chaînes de caractères indépendamment de l’utilisation du langage SQL.

Prenons une requête SQL simple, noter que c’est une chaîne de caractère, qu’il faut donc la délimiter pas des guillemets.

Requete = "SELECT * FROM tutoriels WHERE no=1"

Cet exemple ne pose aucun problème parce qu’il n’y a aucune autre chaîne imbriquée à l’intérieur, simplement parce que la recherche est effectuée sur un nombre (no=1). Mais si vous désirez faire une requête sur un champ " texte " vous devrez ajouter les apostrophes autour de la chaîne à rechercher.

Requete = "SELECT * FROM tutoriels WHERE titre=’titre’"

Puisque notre requête est elle même la construction d’une chaîne de caractère qui va devoir inclure l’identification d’une autre chaîne (et je précise bien L’IDENTIFICATION d’une autre chaîne et non pas la fusion des deux chaînes) il faut utiliser un IDENTIFIANT différent de celui qui identifie notre requête. C’est pourquoi nous utilisons les guillemets pour identifier la chaîne " requête " et l’apostrophe pour identifier la chaîne de recherche. Le contraire est aussi possible :

Requete = ’SELECT * FROM tutoriels WHERE titre="titre"’

Jusque là tout va bien mais si la chaîne de recherche contient une apostrophe ou un guillemet la construction de la chaîne ne sera pas bien interprétée.

Requete = "SELECT * FROM tutoriels WHERE titre=’L’apostrophe démystifiée’"

Ainsi, cette requête provoquera une erreur parce qu’elle ne comprendra pas tout ce qui suit l’apostrophe du L. Or donc, " apostrophe démystifiée’ " sera un intrus dans la construction terminée par le guillemet.

En résumé, indépendamment du SQL, tout langage qui manipule une chaîne de caractères qui contient le même symbole réservé utilisé pour délimiter la chaîne (comme l’apostrophe ou le guillemet) provoquera une erreur.

Var = ’l’apostrophe’; provoquera une erreur en Javascript.

C’est pourquoi tous les langages de programmation utilisent une autre mnémonique pour indiquer que le caractère qui suit ne doit pas être interprété comme un symbole réservé mais bien comme un simple caractère.

Dans la plupart des langages, comme le Javascript, le Java ou JSP, C, etc, c’est la barre oblique ou " slash " \ qui est utilisée. Même chose qu’avec les expressions régulières. Ainsi la barre oblique dans cette chaîne indique que l’apostrophe doit être interprétée comme un caractère. ex : " L\’apostrophe "

En ASP ce n’est pas pareil, il faut doubler le caractère, ex : " L’’apostrophe ". Sacré Microsoft !

Exemple :
"Un ""mot"" entre guillemets" ou ’L’’apostrophe’

En pratique : Une requête.

Vous devez pointer un enregistrement dans une base de données en SQL avec le ASP et l’argument est une chaîne de caractère. Votre recherche s’effectue sur le titre d’un tutoriel par exemple et vous désirez trouver l’enregistrement " L’apostrophe démystifiée ".

Requete = "SELECT * FROM tutoriels WHERE titre=’L’’apostrophe démystifiée’"
Ou
ntitre = "L’’apostrophe démystifiée"
Requete = "SELECT * FROM tutoriels WHERE ntitre=’" & titre & "’"

En pratique : Mise à jour.

La mise à jour c’est la même chose seulement si vous construisez une chaîne SQL, généralement avec " INSERT INTO ".

ntitre = "L’’apostrophe démystifiée"
ntexte = "le texte…"
Requete = "INSERT INTO tutoriels (titre,texte)"
Requete = Requete & "VALUES (’" & ntitre & "’,’" & ntexte & "’)"

Si vous n’utilisez pas de chaîne SQL et modifier directement un champ, vous n’avez pas besoin de doubler les guillemets.

Exemple :

ntitre = "L’apostrophe démystifiée"
ntexte = "le texte…"
connexion.AddNew
connexion.Fields("titre") = ntexte
connexion.Fields("texte") = ntitre
connexion.update

Non seulement cela fonctionne mais si vous aviez doublé l’apostrophe, les deux apostrophes seraient sauvées dans la base.

Automatiser le tout.

Une bonne façon de faire et de créer une petite routine pour convertir les chaînes de caractères.

Exemple :

Function DoubleGuillemets(chaine)
  chaine = Replace(chaine, """, """")
  DoubleGuillemets = chaine
End Function

Function DoubleApost(chaine)
  chaine = Replace(chaine, "’", "’’")
  DoubleApost = chaine
End Function

ntitre = ’L’apostrophe’
DoubleGuillemets (ntitre)
’ ntitre est contient maintenant des guillemets doubles.

Noter que la fonction " Replace " en ASP a très mauvaise réputation, lente etc. Je vous conseil donc de créer votre propre replace qui est considéré plus performant.

Function DoubleApost(chaine)
  Dim i
  Dim modif
  For i = 1 to len(chaine)
    If mid(chaine,i,1)="’" then
      modif = modif & "’’"
    Else
      modif = modif & mid(chaine,i,1)
    End if
  Next
  DoubleApost = modif
End Function

Function DoubleGuillemets(chaine)
  Dim i
  Dim modif
  For i = 1 to len(chaine)
    If mid(chaine,i,1)="’" then
      modif = modif & "’’"
    Else
      modif = modif & mid(chaine,i,1)
    End if
  Next
  DoubleGuillemets = modif
End Function

Petit conseil

Ne sauvegardez jamais dans une base une chaîne modifiée (par exemple avec des doubles guillemets) pensant par la suite éviter un traitement. Sauver toujours vos informations le plus brut possible. Par exemple, n’ajouter pas les balises HREF dans un texte qui comporte des hyperliens. C’est lors de l’affichage d’un texte qu’il faut le manipuler. Ça semble contraire aux pratiques du programmeur de refaire toujours le même traitement qui pourrait être fait une seule fois mais une loi l’emporte cette fois-ci. C’est la loi de la portabilité. En effet, on ne sait jamais ce qui peut arriver à une base de données ni ce que les langages de demain vont nous apporter. Un texte brut sera toujours valide alors qu’un texte altéré pour usage local ne le sera pas.