S'il faut faire d'autres test, il n'y a qu'à demander ;)

bonjour,

c’était juste pour être sur et pouvoir avancé, merci du retour et des tests.

donc windev 17 doit faire quelque chose sur le httpRequete qui visiblement n'existe pas dans les version antérieures.

Lors du test, j'ai mis 'NAVIRE' en clef, j'ai aussi essayé avec un simple 'ABC' donc pas de truc "tordu" et j'avais bien crypteretour à faux

Bonjour,

si vous avez un crypteRetour = faux alors c'est qu'il y a un problème dans les clés

windev17 va crypter la requete on le voit dans le requete=
par contre le script php a mal décrypté la chaine et pourtant au début c'est bon car on a bien le show en clair

essayez de changer les clés pour ne mettre que des caractères alpha pas d'espace pas d'accent pas de chiffres

ce qui est quand même étonnant c'est que windev 16 (et toutes les versions inférieures jusqu’à la 7.5 !!!) fonctionne bien donc la je reste un peu perplexe et je ne vais pas acheter la 17 tout de suite mais c'est dommage que la version 17 apporte des différences dans des traitements qui fonctionnent correctement !

bref faites l'essai en changeant la clé mais cela n’est déjà pas normal

Bonjour,

J'ai exactement le même souci. J'ai découvert PHP4WD il y a peu, je le teste dans un projet avec succès.

Je migre le projet en v17, et plus rien ne fonctionne :(

Si je peux aider à débloquer la situation...

La connexion se passe bien, mais lorsque j'arrive à la commande SQLExec qui liste les tables pour s'assurer que la connexion est OK, là j'ai une erreur:

1 15 --DEBUTSQL--PHP4WDSEP f9
·Failed - err SQL: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'T`amcs eqpk da291361764' at line 1


SHOW T`amcs eqpk da291361764 0

PS: c'est le résultat envoyé avec cryptretour = Faux

le vpost correspondant à la commande est

requete=148138146152098151162164175166181099167180178174098167163117122115118119115122120119&typeBase=MYSQL&bind=&bindLen=&bindVal=&bindType=&methode=NON&crypteretour=NON

Je n'avais pas pensé à ça . J'utilise PHpMyAdmin, mais je n'ai jamais vu de fonction permettant de faire ça sans écrire une requête (mais ça existe peut être). J'ai un autre frontal (dont j'ai oublié le nom). J'irai voir tout ça et au pire j'irai voir le code du datacenter...
Merci

Ca je l'avais fait Firetox.

J'avais utilisé le num 4 pour ma requête principale fonctionnant avec le sqlrecupère et laissé le 0 pour la ou les requêtes imbriqués (de simples sqllitrecherche).

Le endehors est encore à faux après mes requètes imbriquées, car je fais juste la lecture du 1er enregistrement.

Je l'ai malgré tout forcé à faux par sécurité, mais ça ne change rien.

PAR CONTRE, je viens de faire ce que j'explique à la fin de mon message précédent: ai sauvé ma requête initiale dans une variable texte globale et la passe en second paramètre lors de l'appel de sqlRecuperExecute.

et comme ça ça marche !

En regardant le code de cette routine de classe, ça me semble logique que ça fonctionne mieux, car sans la présence de ce second paramètre il utilise myOldQuery pour chercher les rubrique. Or MyOld Query à été entre temps modifié par les requête imbriquées.

Je trouve juste ce fonctionnement un peu bizarre. il me semble qu'il serait plus propre de sauver le texte de la requête correspondant à chaque num de requête dans l'objet SQLMgx (un autre tableau de 5 chaines) . Et que sqlRecupère Exec utilise automatique la bonne requête texte en fonction du numéro de requête qu'on lui donne.

Sais pas si je suis clair...

En tous cas merci encore à toi, ça l'air de fonctionner...

bonjour,

ok dans ces cas la il faut changer les N° de requete sur SQLManagerX par defaut il utilise le 0 pour tous les objets et donc si on fait une imbrication on perd un peu le fil

il suffit de specifier un autre n° pour les objet : chaque methode SQLManagerX attend un n° de requete qui par defaut est 0 donc SQLrecupereExec prend le 0 mais on peu le faire sur d'autre

par contre il faut repasser le mySQLendehor a vrai s'il est a faut quand on change de requete car SQLrecupereExec va tester en premier endehors mais il paut etre postionné par une autre requete que le numero concerné

donc pour faire des SQLrecupereExec imbriqué il faut
par exemple

lire la requete 1
SQLrecupereExec

passez endhors a faux et lire la requete 2
SQLrecupereExec

car si la req 1 passe endehors a faux le recupere dans le 2 sortira immediatement

SQLrecupereExec recupere les info pour les mettre dans les objets sur la ligne en cours de la requete passé en parametre et pour eviter de se planter il test le endehors

donc en imbrication il faut penser a cela

Ok je vais regarder le cote Endehors, mais en regardant de plus près ce qui ce passe, j'ai l'impression qu'il y a autre chose:

Le resultat de ma 1ere requete est bien conservé dans l'object SQLMx, lorsque je lance ma seconde requête (normal, il y a cinq tableaux Resultatn de prévu), mais il y a un seul "myOldQuery" qui contient la requete.

Lors du lancement de la seconde requete, elle remplace la valeur dans "myOldQuery".

Comme cette chaine est utilisée par SQLRecupèreExec pour reconnaitre les colonnes à assigner aux objets, il ne s'y retrouve plus.

Je vois par contre, que l'on peut lui passer un second paramètre (pas documenté dans la doc mais vu dans le code), contenant le nom d'une requete...
Faut-il que je sauve ma chaine de caractère contenant 1ere requete dans une variable texte pour la passer en second paramètre à SQLRecupèreExec.

Bon j'essaie...

Bonjour,

non c'est le mySQLEndehors qui est commun et donc qui n'est pas a jour il a ete positionné par la deuxieme requete a vrai il faut le repasser a faux dans ce cas

exemple
je fais une requete
je lis le premier
je fair une autre requete

si apres je test endehors il est a vrai et donc je sort

dans certain code et pour forcer le programmeur a savoir ce qui se passe il suffit de dire ok je sais que endehors est a vrai ca la 2 eme requete est terminée mais je le repasse a faux pour la requete plus haut

c'est tout le probleme des endehors qui ne sont pas lié dans les dll a la requete mais a l'objet lu donc la ligne en cours mais independement du n° de requete