Pb préparation requête MySQL

Si j'exécute une requête SQL à partir de l'éditeur XMLGram, pas de problème j'obtiens une réponse normale.
Si j'exécute la même requête à partir de l'application en cours d'exécution, j'obtiens l'erreur suivante :
TDacQuery.GetPreparedQuery - TDacMySQLQuery.Prepare41 - Query was empty

C'est marrant, mais avec la même base sous Access, j'ai un comportement similaire. Dans l'EDI, la requête passe nickel. A partir de l'application, une erreur me sort :
TDacQuery.Open - Instruction SQL non valide; 'DELETE', 'INSERT', 'PROCEDURE', 'SELECT' ou 'UPDATE' attendus

Quelque soit le moteur SGBD, c'est comme si la requête exécutée était vide ?!

Pourtant si je regarde les logs :

• TDacQuery.GetPreparedQuery - TDacMySQLQuery.Prepare41 - Query was empty
• TDBExtract.DoProcess.OpenStatement
• TDBExtract.DoProcess - Name=T_CELLULES SELECT T_CELLULES.ID, T_CELLULES.CELLULE, T_CELLULES.cellule_sans_zero, T_CELLULES.adresse, T_CELLULES.departement, T_CELLULES.localite, T_CELLULES.opt FROM T_CELLULES T_CELLULES WHERE T_CELLULES.CELLULE LIKE '%1245%' AND (OPERATEUR like 'TOTO') ORDER BY T_CELLULES.opt ASC

La requête a exécuter n'est pas vide !

[XMLRAD 2006R1, Windows Server 2003, MySQL 5.0]

--> Précisons que je bosse avec Sylvain sur ce projet ...

Hier soir, sur ma bécanne de dev (XMLRAD 2006 / XP / IIS) je bosse avec les même sources mais avec ACCESS comme BDD.

Alors que ça marchait nickel, j'ai trifouillé la pagination dans mon xmlGram (je suis passé d'un Nb. max. résultats : de 20 à Tous les enregistrements).

Et là ... même erreur que toi !!

Citation:

---

TDacQuery.Open - Instruction SQL non valide; 'DELETE', 'INSERT', 'PROCEDURE', 'SELECT' ou 'UPDATE' attendus

---

GRRRRR !!!

Du coup je suis parti en maudissant XMLRAD (ben oui ça arrive ...).

Ce matin ... plein de bonne humeur , je procède à quelques investigations ...

Dans le fichier XMLGRAM , cette ligne attire mon attention:

Code:

---

<ExactPagingStatement><![CDATA[ ]]></ExactPagingStatement>

---

Par acquis de conscience je vire la tabulation dans mon CDATA...

Code:

---

<ExactPagingStatement><![CDATA[]]></ExactPagingStatement>

---

Et là surprise !!! ... it works ... j'ai reproduit l'erreur plusieurs fois avec succès ...

Est-ce la "very definitive solution" de ton problème en particulier ... mystère mais c'est bien parti !!!

A SUIVRE

ah mais c'est bien sur !
L'exact paging envoyait implicitement une autre requête (ça mérite d'être ajouté dans le log ça !). Ce qui explique que malgré le SGBD, on retrouve le pb.
Zut je crois que j'avais pas regardé les traces. Et pis encore une fois ça aurait pu être détecté en traçant pas à pas le framework.
Eric si jamais c'est marqué dans les traces, tu as le droit de me flageller en public ;-)
Joli 8-) je lève toutes tes sanctions pour mauvais comportement en espace collectif... :lol:

Merci !

regarde dans le log d'erreur mais je crois que la requête incriminée est loggée.
d'autre part tu avais déjà eu le problème... quand j'ai lu ton post, j'ai tout de suite pensé à cela. :)

Citation:

---

Envoyé par RDM

regarde dans le log d'erreur mais je crois que la requête incriminée est loggée.
d'autre part tu avais déjà eu le problème... quand j'ai lu ton post, j'ai tout de suite pensé à cela. :)

---

Dans le log d'erreur j'ai juste ce que j'ai indiqué dans mon premier post. Je viens de vérifier dans les sources 2006R1, et je ne vois rien qui pushe dans le log l'excution SQL de l'exactpaging. Tout au moins peut-on regarder ExactPagingStatement et ExactPaging dans le context me semble-t-il. J'ai pas le projet sous les yeux là mais je vérifierai demain.

Je ne me rapelle pas avoir déjà rencontré ce pb, à moins que je devienne amnésique, soit tu te trompes de zozo soit je suis devenu zozo (enfin un peu plus que d'hab ;-))

Citation:

---

Envoyé par RDM

regarde dans le log d'erreur mais je crois que la requête incriminée est loggée.
d'autre part tu avais déjà eu le problème... quand j'ai lu ton post, j'ai tout de suite pensé à cela. :)

---

Ca me fait penser qu'il faudrait remonter à l'éditeur qu'ils fassent un trim() sur ExactPagingStatement avant de tester si c'est vide. On sait jamais qu'un éditeur ou un autre n'insère d'espaces malencontreusement.

tu avait eu le problème avec MySQL et la casse du nom des tables.
la requête qui ne passait pas étati celle de l'exact Paging !
Effectivement, la requête exactPaging n'est pas loggée.

Citation:

---

Envoyé par RDM

tu avait eu le problème avec MySQL et la casse du nom des tables.
la requête qui ne passait pas étati celle de l'exact Paging !
Effectivement, la requête exactPaging n'est pas loggée.

---

Ah oui je m'en rappelle maintenant ! Je ne me souvenait pas que c'était celle de l'exact paging.

RDM tu viens de gagner le droit de rédiger mes mémoires, respect ! 8-)

;)