Discussion :

[JCD59]

Bonjour;

Je désire transmettre à une requête SQL le résultat d'un composant dbedit, cependant ma rédaction ( anciennement Delphi) ne fonctionne pas

datamodule1.ZQuery_films.SQL.Add('where NUM_ENT =" ' + dbedit1.Text + ' " ' ) ;

J'ai toujours une erreur, surement une histoire de guillemets

Pour le moment j'ai contourné la difficulté en intercalant un Edit.text avec comme code

edit1.Text:='where NUM_ENT =' + dbedit1.Text;
with datamodule1.Zquery_films do
datamodule1.Zquery_films.Close;
datamodule1.ZQuery_films.SQL.Clear;
datamodule1.ZQuery_films.SQL.LoadFromFile('query2.sql');
datamodule1.ZQuery_films.SQL.Add (edit1.Text);

Mais ce n'est pas top , merci de me corriger

[acaumes]

Bonjour,

Ce que je remarques comme différences entre les deux c'est l'utilisation de guillemets (") dans ta première expression et pas dans la seconde.

Si ton champ n'est pas de formate texte, c'est probablement l'explication.

NB. Tu ne vérifies rien dans ton champ est ce fait avant? Sinon attention aux injections SQL.

Cordialement

[alanglet]

Bonjour,

En SQL une chaîne de caractères doit être encadrée de simples apostrophes. Mais pour transmettre une apostrophe en Pascal, cette apostrophe doit être doublée. Donc dans votre première forme, vous devriez remplacer vos guillemets par 2 simples apostrophes.
Par ailleurs, pouvez-vous être sûr que dans votre champ dbedit1, le texte ne comprendra pas lui-même une apostrophe? QuotedStr(dbedit1.text) se charge d'encadrer le texte de simples apostrophes et de doubler celles qui s'y trouvent.
Il existe aussi la possibilité de remplacer votre chaîne par un paramètre :machaine dans le texte de votre requête puis avant d'exécuter la requête de définir ParamByName('machaine').asstring qui se charge d'encadrer et doubler les apostrophes.

André

[anapurna]

salut

pour eviter ce genre d'ecueuille je recommende d'utiliser la fonction format

Code :

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

DM.ZQuery_films.SQL.Add(Format('where NUM_ENT = %s ',[dbedit1.Text ]) ) ;

[Jon Shannow]

Bonjour,

Tout ce qui dit avant est juste, mais, quid du type de champ NUM_ENT. Si c'est un numérique, ça explique que la seconde syntaxe fonctionne et pas la première.

JS

PS : Dans tous les cas, je préfère passer par des paramètres, comme l'a dit alanglet

[alanglet]

Bonjour,

Tout ce qui dit avant est juste, mais, quid du type de champ NUM_ENT. Si c'est un numérique, ça explique que la seconde syntaxe fonctionne et pas la première.

Effectivement, comme JCD59 cherchait dbEdit1.Text je pensais que NUM_ENT était du type VARCHAR. Si la deuxième forme proposée fonctionne, c'est que "hasard fait bien les choses", et que NUM_ENT est sans doute un entier. Mais pourquoi compliquer les choses en modifiant dbEdit1.Text? d'autant plus qu'il faut alors que ce champ soit éditable, et ça ne fonctionnera qu'une fois...

pour éviter ce genre d'écueil je recommande d'utiliser la fonction format

Code :

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

DM.ZQuery_films.SQL.Add(Format('where NUM_ENT = %s ',[dbedit1.Text ]) ) ;

Ne fonctionnera également que si NUM_ENT est un entier, car la fonction format n'ajoute pas les apostrophes nécessaires si c'est une chaîne de caractères.

André

[e-ric]

Salut

Deux remarques:
- l'emploi d'un paramètre n'est pas vraiment une option et est largement préconisé (éviter les problèmes rencontrés ici), en outre, cela sécurise le code en rendant difficile une injection SQL (volontaire ou non)
- le code

Code :

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

datamodule1.ZQuery_films.SQL.Add('where NUM_ENT =" ' + dbedit1.Text + ' " ' );

pourrait être remplacé par quelques chose comme

Code :

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

datamodule1.SetPrmNumFilm(dbedit1.Text);

méthode dans laquelle tu affectes le paramètre, afin de rendre le client du DataModule indépendant de l'implémentation de la recherche dans ce dernier. en effet, si dans le futur, tu dois remplacer Zeos par SQLdb, il te faudra revoir le DataModule, mais aussi tous les clients de ce DataModule.

Voilà pour ma contribution de début de semaine.

@+

[hmira]

Bonjour,

1 - Le premier point le plus important, il a été soulevé, à juste titre, par Jon Shannow, concerne le type de la colonne NUM_ENT tel qu'elle est est définie au niveau de la base de données. Quel est le type de la colonne NUM_ENT (s'agit-il d'un Integer, d'un Varchar, D'une Date, d'une Datetime, d'une Image etc. ? .
NB : le type Image est là la juste pour la provocation ! Ceci dit tout est possible.

Sinon on peut supposer que la colonne NUM_ENT est de type Integer, mais encore faut-il que cela soit confirmé (?)

2 - Le 2ème point aussi important est l'utilisation des paramètres. Cela a été très bien rappelé par e-ric (L'utilisation des paramètres n'est pas une simple option, il y a là des considérations de sécurité, se prémunir des injections SQL etc..).

3 - Le 3ème point hyper important, non évoqué ! il concerne les problèmes de performance dus aux éventuels transtypages implicites effectués au niveau de la base de données, lorsque l'argument ou le type du paramètre ne correspond pas ou n'est pas en cohérence avec le type de la colonne.

Imaginons que la colonne NUM_ENT est de type INT (Integer) et que le développeur, lors de la construction de la requête SQL , n'a pas respecté le type de la colonne dans la clause de la restriction WHERE, et que, la requête finale exécutée sur le Serveur de base de données est la suivante
SELECT Col1, Col2, ...
FROM MaTable
WHERE NUM_ENT = '1754'

Certains Serveur de base de données ne vont 'brancher' et considéreront que la requête est syntaxiquement correcte. Ils vont toutefois effectuer un Transtypage implicite pour convertir la chaine '1754' en un integer 1754 . Le Transtypage implicite est généralement très néfaste pour les performances. Dans des cas extrêmes, l'expression de la clause WHERE, peut devenir "NON-SARG" (NON Searchable ARGument) c.à.d. aucun index existant, censés optimiser l'accès aux données, ne pourra être utilisé (1) ! un FULL SCAN sera effectué sur la table et si par "chance" la table contient plusieurs dizaines de millions de lignes la requête SQL au lieu de mettre quelque millisecondes, mettra plusieurs dizaines de minutes (exemple 30 ou 40 minutes !)
PS : Je ne dis pas que dans le cas présent on passerait de quelques millisecondes à quelques dizaines de minutes, mais plus généralement, l'expérience montre que dès lors que l'on ne respecte pas le type des colonnes dans les expressions WHERE, il n'est pas rare que l'on s'expose à ce genre de situation catastrophique en terme de performance.

(1) : En effet, l'optimiseur de requête, avant de décider de l'utilisation de tel ou tel index, se base sur les statistiques. Les statistiques établissent des échantillonnages sur les valeurs brutes des colonnes (et non pas sur des valeurs transformées par une quelconque fonction scalaire), et ce, pour en déterminer la densité et la sélectivité. Le Transtypage implicite est assimilable à une transformation par une fonction scalaire (Exemple sous ORACLE : TO_NUMBER( ... ) ou SQL Server : CAST( ... AS INT ) et donc les statistiques établies sur des valeurs brutes ne seront d'aucune utilité : CQFD.

A+

[JCD59]

Bonjour,

Après quelques jours d'absence, je prends connaissance de vos réponses ce dont je vous remercie.

Je viens d'en faire un rapide survol, et je vais approfondir.

Comme certains l'ont supposé, NUM_ENT est bien de type integer, et c'est une clé primaire.

J'avais transposé ma requête que j'avais utilisée avec une base Paradox sous Delphi 7