Un problème très curieux : j'ai créé une requête sous l'éditeur intégré
et cette requête contient une clause IN.
SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN
(1,2,4)
Si je définis le contenu de cette clause comme une liste de valeurs (que
j'entre directement dans la condition), aucun problème.
SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN
(1,2,4)
Si j'indique que le contenu du IN provient d'un paramètre et que, à
l'exécution de la requête, je rentre les mêmes valeurs que ci-dessus,
seul l'enregistrement correspondant au premier membre de la liste m'est
retourné (si les valeurs sont numériques car, dans le cas d'un IN avec
une liste de valeurs alpha, rien n'est retourné).
Je donne la valeur "1,2,4" à Param1
SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN
({Param1})
Le résultat est le même si j'exécute la requête depuis mon programme
avec ExecuteRequete en lui passant ma liste de paramètres.
Je précise que si je copie le code SQL de la requête dans mon programme
et que je l'exécute avec ma liste de valeurs en paramètre par
ExecuteRequeteSQL, ça fonctionne.
Quelqu'un a-t-il eu ce genre de problème avec la clause IN ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
jacques trepp
Eric wrote:
Bonjour,
Un problème très curieux : j'ai créé une requête sous l'éditeur intégré et cette requête contient une clause IN. SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN (1,2,4)
Si je définis le contenu de cette clause comme une liste de valeurs (que j'entre directement dans la condition), aucun problème. SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN (1,2,4)
Si j'indique que le contenu du IN provient d'un paramètre et que, à l'exécution de la requête, je rentre les mêmes valeurs que ci-dessus, seul l'enregistrement correspondant au premier membre de la liste m'est retourné (si les valeurs sont numériques car, dans le cas d'un IN avec une liste de valeurs alpha, rien n'est retourné). Je donne la valeur "1,2,4" à Param1 SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN ({Param1})
Bonsoir, et si tu fais : g_requete est une chaine g_requete = "SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN ("+Param1+")" ça doit bien de donner comme requete : SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN (1,2,4) Non ?
Jacques TREPP AlbyGest
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.662 / Virus Database: 425 - Release Date: 20/04/2004
Eric wrote:
Bonjour,
Un problème très curieux : j'ai créé une requête sous l'éditeur
intégré et cette requête contient une clause IN.
SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN
(1,2,4)
Si je définis le contenu de cette clause comme une liste de valeurs
(que j'entre directement dans la condition), aucun problème.
SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN
(1,2,4)
Si j'indique que le contenu du IN provient d'un paramètre et que, à
l'exécution de la requête, je rentre les mêmes valeurs que ci-dessus,
seul l'enregistrement correspondant au premier membre de la liste
m'est retourné (si les valeurs sont numériques car, dans le cas d'un
IN avec une liste de valeurs alpha, rien n'est retourné).
Je donne la valeur "1,2,4" à Param1
SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN
({Param1})
Bonsoir,
et si tu fais :
g_requete est une chaine
g_requete = "SELECT Client.Nom, Client.Prenom FROM Client WHERE
Client.CleUnique IN ("+Param1+")"
ça doit bien de donner comme requete :
SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN
(1,2,4)
Non ?
Jacques TREPP
AlbyGest
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.662 / Virus Database: 425 - Release Date: 20/04/2004
Un problème très curieux : j'ai créé une requête sous l'éditeur intégré et cette requête contient une clause IN. SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN (1,2,4)
Si je définis le contenu de cette clause comme une liste de valeurs (que j'entre directement dans la condition), aucun problème. SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN (1,2,4)
Si j'indique que le contenu du IN provient d'un paramètre et que, à l'exécution de la requête, je rentre les mêmes valeurs que ci-dessus, seul l'enregistrement correspondant au premier membre de la liste m'est retourné (si les valeurs sont numériques car, dans le cas d'un IN avec une liste de valeurs alpha, rien n'est retourné). Je donne la valeur "1,2,4" à Param1 SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN ({Param1})
Bonsoir, et si tu fais : g_requete est une chaine g_requete = "SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN ("+Param1+")" ça doit bien de donner comme requete : SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN (1,2,4) Non ?
Jacques TREPP AlbyGest
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.662 / Virus Database: 425 - Release Date: 20/04/2004
Eric
Le 21 avril 2004 à 17:55, jacques trepp nous disait :
et si tu fais : g_requete est une chaine g_requete = "SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN ("+Param1+")" ça doit bien de donner comme requete : SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN (1,2,4) Non ?
Là, tu me proposes de passer par ExecuteRequeteSQL et, comme je le signale, ça marche ! Le problème se pose avec les requêtes créees sous l'éditeur, que ce soit en exécution depuis l'éditeur ou depuis mon programme avec ExecuteRequete.
-- Cordialement
Le 21 avril 2004 à 17:55, jacques trepp nous disait :
et si tu fais :
g_requete est une chaine
g_requete = "SELECT Client.Nom, Client.Prenom FROM Client WHERE
Client.CleUnique IN ("+Param1+")"
ça doit bien de donner comme requete :
SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN
(1,2,4)
Non ?
Là, tu me proposes de passer par ExecuteRequeteSQL et, comme je le
signale, ça marche ! Le problème se pose avec les requêtes créees sous
l'éditeur, que ce soit en exécution depuis l'éditeur ou depuis mon
programme avec ExecuteRequete.
Le 21 avril 2004 à 17:55, jacques trepp nous disait :
et si tu fais : g_requete est une chaine g_requete = "SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN ("+Param1+")" ça doit bien de donner comme requete : SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN (1,2,4) Non ?
Là, tu me proposes de passer par ExecuteRequeteSQL et, comme je le signale, ça marche ! Le problème se pose avec les requêtes créees sous l'éditeur, que ce soit en exécution depuis l'éditeur ou depuis mon programme avec ExecuteRequete.
-- Cordialement
Roumegou
Il se trouve que Eric a formulé :
Le 21 avril 2004 à 17:55, jacques trepp nous disait :
et si tu fais : g_requete est une chaine g_requete = "SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN ("+Param1+")" ça doit bien de donner comme requete : SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN (1,2,4) Non ?
Là, tu me proposes de passer par ExecuteRequeteSQL et, comme je le signale, ça marche ! Le problème se pose avec les requêtes créees sous l'éditeur, que ce soit en exécution depuis l'éditeur ou depuis mon programme avec ExecuteRequete.
Faut-il utiliser cet éditeur ? là est la question. Pour ma part, j'ai essayé une fois et j'ai abandonné car c'était vraiment trop limité.
-- Eric Roumegou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Il se trouve que Eric a formulé :
Le 21 avril 2004 à 17:55, jacques trepp nous disait :
et si tu fais :
g_requete est une chaine
g_requete = "SELECT Client.Nom, Client.Prenom FROM Client WHERE
Client.CleUnique IN ("+Param1+")"
ça doit bien de donner comme requete :
SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN
(1,2,4)
Non ?
Là, tu me proposes de passer par ExecuteRequeteSQL et, comme je le
signale, ça marche ! Le problème se pose avec les requêtes créees sous
l'éditeur, que ce soit en exécution depuis l'éditeur ou depuis mon
programme avec ExecuteRequete.
Faut-il utiliser cet éditeur ? là est la question.
Pour ma part, j'ai essayé une fois et j'ai abandonné car c'était
vraiment trop limité.
--
Eric Roumegou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
Le 21 avril 2004 à 17:55, jacques trepp nous disait :
et si tu fais : g_requete est une chaine g_requete = "SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN ("+Param1+")" ça doit bien de donner comme requete : SELECT Client.Nom, Client.Prenom FROM Client WHERE Client.CleUnique IN (1,2,4) Non ?
Là, tu me proposes de passer par ExecuteRequeteSQL et, comme je le signale, ça marche ! Le problème se pose avec les requêtes créees sous l'éditeur, que ce soit en exécution depuis l'éditeur ou depuis mon programme avec ExecuteRequete.
Faut-il utiliser cet éditeur ? là est la question. Pour ma part, j'ai essayé une fois et j'ai abandonné car c'était vraiment trop limité.
-- Eric Roumegou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Eric
Le 21 avril 2004 à 18:17, Roumegou nous disait :
Là, tu me proposes de passer par ExecuteRequeteSQL et, comme je le signale, ça marche ! Le problème se pose avec les requêtes créees sous l'éditeur, que ce soit en exécution depuis l'éditeur ou depuis mon programme avec ExecuteRequete.
Faut-il utiliser cet éditeur ? là est la question. Pour ma part, j'ai essayé une fois et j'ai abandonné car c'était vraiment trop limité.
Pour des requêtes simples, du genre de celles qui alimentent des tables, c'est pratique. Et je trouve qu'il a fait des progrès significatifs en v8. Sauf pour les clauses IN... :-)
-- Cordialement
Le 21 avril 2004 à 18:17, Roumegou nous disait :
Là, tu me proposes de passer par ExecuteRequeteSQL et, comme je le
signale, ça marche ! Le problème se pose avec les requêtes créees sous
l'éditeur, que ce soit en exécution depuis l'éditeur ou depuis mon
programme avec ExecuteRequete.
Faut-il utiliser cet éditeur ? là est la question.
Pour ma part, j'ai essayé une fois et j'ai abandonné car c'était
vraiment trop limité.
Pour des requêtes simples, du genre de celles qui alimentent des tables,
c'est pratique. Et je trouve qu'il a fait des progrès significatifs en
v8. Sauf pour les clauses IN... :-)
Là, tu me proposes de passer par ExecuteRequeteSQL et, comme je le signale, ça marche ! Le problème se pose avec les requêtes créees sous l'éditeur, que ce soit en exécution depuis l'éditeur ou depuis mon programme avec ExecuteRequete.
Faut-il utiliser cet éditeur ? là est la question. Pour ma part, j'ai essayé une fois et j'ai abandonné car c'était vraiment trop limité.
Pour des requêtes simples, du genre de celles qui alimentent des tables, c'est pratique. Et je trouve qu'il a fait des progrès significatifs en v8. Sauf pour les clauses IN... :-)
-- Cordialement
Dev
Bonjour, la rétro-analyse à l'air de commencer à fonctionner et dans certains cas, il est plus simple d'écrire la requête à la main, puis de la retro-analyser. Par contre il est toujours impossible de mettre des valeurs négatives dans les In, et ce depuis toujours!!
-- Cordialement Christophe Charron
Service Développement PROLOGIQ 7 bis Rue des Aulnes 69410 Champagne au Mont d'Or
Tel : 0 437 499 107 Fax : 0 437 499 105 mailto:
"Eric" <ericb33+ a écrit dans le message de news:
Le 21 avril 2004 à 18:17, Roumegou nous disait :
>> Là, tu me proposes de passer par ExecuteRequeteSQL et, comme je le >> signale, ça marche ! Le problème se pose avec les requêtes créees sous >> l'éditeur, que ce soit en exécution depuis l'éditeur ou depuis mon >> programme avec ExecuteRequete. > > Faut-il utiliser cet éditeur ? là est la question. > Pour ma part, j'ai essayé une fois et j'ai abandonné car c'était > vraiment trop limité.
Pour des requêtes simples, du genre de celles qui alimentent des tables, c'est pratique. Et je trouve qu'il a fait des progrès significatifs en v8. Sauf pour les clauses IN... :-)
-- Cordialement
Bonjour,
la rétro-analyse à l'air de commencer à fonctionner et dans certains cas, il
est plus simple d'écrire la requête à la main, puis de la retro-analyser.
Par contre il est toujours impossible de mettre des valeurs négatives dans
les In, et ce depuis toujours!!
--
Cordialement
Christophe Charron
Service Développement
PROLOGIQ
7 bis Rue des Aulnes
69410 Champagne au Mont d'Or
"Eric" <ericb33+spam@alussinan.org> a écrit dans le message de
news:1i56r57ae23qq.dlg@ericb33spam.alussinan.org...
Le 21 avril 2004 à 18:17, Roumegou nous disait :
>> Là, tu me proposes de passer par ExecuteRequeteSQL et, comme je le
>> signale, ça marche ! Le problème se pose avec les requêtes créees sous
>> l'éditeur, que ce soit en exécution depuis l'éditeur ou depuis mon
>> programme avec ExecuteRequete.
>
> Faut-il utiliser cet éditeur ? là est la question.
> Pour ma part, j'ai essayé une fois et j'ai abandonné car c'était
> vraiment trop limité.
Pour des requêtes simples, du genre de celles qui alimentent des tables,
c'est pratique. Et je trouve qu'il a fait des progrès significatifs en
v8. Sauf pour les clauses IN... :-)
Bonjour, la rétro-analyse à l'air de commencer à fonctionner et dans certains cas, il est plus simple d'écrire la requête à la main, puis de la retro-analyser. Par contre il est toujours impossible de mettre des valeurs négatives dans les In, et ce depuis toujours!!
-- Cordialement Christophe Charron
Service Développement PROLOGIQ 7 bis Rue des Aulnes 69410 Champagne au Mont d'Or
Tel : 0 437 499 107 Fax : 0 437 499 105 mailto:
"Eric" <ericb33+ a écrit dans le message de news:
Le 21 avril 2004 à 18:17, Roumegou nous disait :
>> Là, tu me proposes de passer par ExecuteRequeteSQL et, comme je le >> signale, ça marche ! Le problème se pose avec les requêtes créees sous >> l'éditeur, que ce soit en exécution depuis l'éditeur ou depuis mon >> programme avec ExecuteRequete. > > Faut-il utiliser cet éditeur ? là est la question. > Pour ma part, j'ai essayé une fois et j'ai abandonné car c'était > vraiment trop limité.
Pour des requêtes simples, du genre de celles qui alimentent des tables, c'est pratique. Et je trouve qu'il a fait des progrès significatifs en v8. Sauf pour les clauses IN... :-)
-- Cordialement
Antoine
Dev wrote:
Bonjour, la rétro-analyse à l'air de commencer à fonctionner et dans certains cas, il est plus simple d'écrire la requête à la main, puis de la retro-analyser. Par contre il est toujours impossible de mettre des valeurs négatives dans les In, et ce depuis toujours!!
"Eric" <ericb33+ a écrit dans le message de news:
Le 21 avril 2004 à 18:17, Roumegou nous disait :
Là, tu me proposes de passer par ExecuteRequeteSQL et, comme je le signale, ça marche ! Le problème se pose avec les requêtes créees sous l'éditeur, que ce soit en exécution depuis l'éditeur ou depuis mon programme avec ExecuteRequete.
Faut-il utiliser cet éditeur ? là est la question. Pour ma part, j'ai essayé une fois et j'ai abandonné car c'était vraiment trop limité.
Pour des requêtes simples, du genre de celles qui alimentent des tables, c'est pratique. Et je trouve qu'il a fait des progrès significatifs en v8. Sauf pour les clauses IN... :-)
-- Cordialement
Tu as la réponse sur le forum de pcsoft. Cet éditeur est capable de faire ce traitement. toutefois, comme c'est indiqué dans la doc, le séparateur de parametres n'est pas "," mais RC ou TAB ou ";".
Dev wrote:
Bonjour,
la rétro-analyse à l'air de commencer à fonctionner et dans certains
cas, il est plus simple d'écrire la requête à la main, puis de la
retro-analyser. Par contre il est toujours impossible de mettre des
valeurs négatives dans les In, et ce depuis toujours!!
"Eric" <ericb33+spam@alussinan.org> a écrit dans le message de
news:1i56r57ae23qq.dlg@ericb33spam.alussinan.org...
Le 21 avril 2004 à 18:17, Roumegou nous disait :
Là, tu me proposes de passer par ExecuteRequeteSQL et, comme je le
signale, ça marche ! Le problème se pose avec les requêtes créees
sous l'éditeur, que ce soit en exécution depuis l'éditeur ou
depuis mon programme avec ExecuteRequete.
Faut-il utiliser cet éditeur ? là est la question.
Pour ma part, j'ai essayé une fois et j'ai abandonné car c'était
vraiment trop limité.
Pour des requêtes simples, du genre de celles qui alimentent des
tables, c'est pratique. Et je trouve qu'il a fait des progrès
significatifs en v8. Sauf pour les clauses IN... :-)
--
Cordialement
Tu as la réponse sur le forum de pcsoft. Cet éditeur est capable de faire ce
traitement.
toutefois, comme c'est indiqué dans la doc, le séparateur de parametres
n'est pas "," mais RC ou TAB ou ";".
Bonjour, la rétro-analyse à l'air de commencer à fonctionner et dans certains cas, il est plus simple d'écrire la requête à la main, puis de la retro-analyser. Par contre il est toujours impossible de mettre des valeurs négatives dans les In, et ce depuis toujours!!
"Eric" <ericb33+ a écrit dans le message de news:
Le 21 avril 2004 à 18:17, Roumegou nous disait :
Là, tu me proposes de passer par ExecuteRequeteSQL et, comme je le signale, ça marche ! Le problème se pose avec les requêtes créees sous l'éditeur, que ce soit en exécution depuis l'éditeur ou depuis mon programme avec ExecuteRequete.
Faut-il utiliser cet éditeur ? là est la question. Pour ma part, j'ai essayé une fois et j'ai abandonné car c'était vraiment trop limité.
Pour des requêtes simples, du genre de celles qui alimentent des tables, c'est pratique. Et je trouve qu'il a fait des progrès significatifs en v8. Sauf pour les clauses IN... :-)
-- Cordialement
Tu as la réponse sur le forum de pcsoft. Cet éditeur est capable de faire ce traitement. toutefois, comme c'est indiqué dans la doc, le séparateur de parametres n'est pas "," mais RC ou TAB ou ";".
Eric
Le 23 avril 2004 à 07:25, Antoine nous disait :
Tu as la réponse sur le forum de pcsoft. Cet éditeur est capable de faire ce traitement. toutefois, comme c'est indiqué dans la doc, le séparateur de parametres n'est pas "," mais RC ou TAB ou ";".
Voilà ma réponse dans le forum PC Soft (pour ceux qui ne le liraient pas) :
C'est exact. Cependant, si en description de requête j'indique que ma rubrique est dans une liste de valeurs/paramètres et que j'indique 2 valeurs, ces valeurs sont séparées par une virgule lorsque je visualise le code SQL généré. D'autre part, si j'écris ma requête à la main, avec des valeurs séparées par des virgules, et que je l'exécute avec ExecuteRequeteSQL, ça fonctionne aussi. C'est pourquoi je trouve ces différences pas très cohérentes.
-- Cordialement
Le 23 avril 2004 à 07:25, Antoine nous disait :
Tu as la réponse sur le forum de pcsoft. Cet éditeur est capable de faire ce
traitement.
toutefois, comme c'est indiqué dans la doc, le séparateur de parametres
n'est pas "," mais RC ou TAB ou ";".
Voilà ma réponse dans le forum PC Soft (pour ceux qui ne le liraient
pas) :
C'est exact. Cependant, si en description de requête j'indique que ma
rubrique est dans une liste de valeurs/paramètres et que j'indique 2
valeurs, ces valeurs sont séparées par une virgule lorsque je visualise
le code SQL généré.
D'autre part, si j'écris ma requête à la main, avec des valeurs séparées
par des virgules, et que je l'exécute avec ExecuteRequeteSQL, ça
fonctionne aussi.
C'est pourquoi je trouve ces différences pas très cohérentes.
Tu as la réponse sur le forum de pcsoft. Cet éditeur est capable de faire ce traitement. toutefois, comme c'est indiqué dans la doc, le séparateur de parametres n'est pas "," mais RC ou TAB ou ";".
Voilà ma réponse dans le forum PC Soft (pour ceux qui ne le liraient pas) :
C'est exact. Cependant, si en description de requête j'indique que ma rubrique est dans une liste de valeurs/paramètres et que j'indique 2 valeurs, ces valeurs sont séparées par une virgule lorsque je visualise le code SQL généré. D'autre part, si j'écris ma requête à la main, avec des valeurs séparées par des virgules, et que je l'exécute avec ExecuteRequeteSQL, ça fonctionne aussi. C'est pourquoi je trouve ces différences pas très cohérentes.
