|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| [WD12] Acces natif MySQL 5.1.73 |
| Débuté par I.G.LOG, 19 déc. 2015 10:39 - 6 réponses |
| |
| | | |
|
| |
Posté le 19 décembre 2015 - 10:39 |
Bonjour à tous,
J'ai un problème avec la fonction SQLExec et avec un client LibMySQL.dll
version 5.1.73 (même version que le serveur MySQL).
SQLExec avec la requête suivante retourne Faux avec un code erreur n° 00000:
select t_col.ID_COL, t_caract._NOM, t_col._TYPE, t_col._LONG
from t_col
inner join t_caract
on t_caract.ID_CAR = t_col.ID_CAR
where t_col.ID_TBL = 6 // erreur n° 00000
Cette requête est pourtant valide puisque je l'exécute sans problème dans
MySQL.
Par ailleurs, j'ai un client libmysql.dll - dont je ne connais pas la
version (taille 1044 Ko du 14/02/2005) - avec lequel cette requête
fonctionne (et toutes les autres d'ailleurs)
Mais j'aimerais utiliser les bonnes versions de MySQL.
Et là je ne comprend pas le problème. SQLExec boggué ? Limité ?
Merci pour vos réponses |
| |
| |
| | | |
|
| | |
| |
Posté le 05 juillet 2017 - 14:27 |
Bonjour,
Le sujet est ancien mais reste d'actualité.
Il faut noter qu'une requête simple du type "SELECT * FROM machin" fonctionne. Même si on ajoute quelques jointures. Ce n'est que quand la requête devient un peu velue, avec des fonctions (d'agrégations ou non) dans le SELECT ou des sous-requêtes, que le problème survient au SQLExec().
Si quelqu'un peut nous aider ce serait vraiment sympa. Inutile de nous dire de passer à Windev 22 ou de prendre la vielle libmysql.dll qui fonctionne. Des contraintes externes nous empêche de le faire. A la limite, s'il y a moyen "d'aiguiller" l’accès natif vers une libmysql.dll qui serait dans un autre répertoire que celui de l'exécutable, je prends.
J'ai essayé de modifier les formats de chaîne envoyés aux commandes sqlXXX() natives, peine perdue. Le fait que l'erreur retournée soit "00000" me fait penser qu'il y a erreur de l'accès natif et non de la DLL mySQL.
J'utilise une classe qui encapsule les appels à l'accès natif aussi m'est-il possible d'utiliser directement les fonctions de libmysql.dll ou le package .NET de MySQL. Mais ça me ferait bien (bip) d'être obligé d'en arriver là alors qu'il y a peut-être une solution à portée de main.
Merci de toute l'aide que vous pourrez m'apporter car c'est très pénible. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
3 messages |
|
Posté le 05 juillet 2017 - 14:38 |
Bonjour,
Le sujet est ancien mais reste d'actualité.
Il faut noter qu'une requête simple du type "SELECT * FROM machin" fonctionne. Même si on ajoute quelques jointures. Ce n'est que quand la requête devient un peu velue, avec des fonctions (d'agrégations ou non) dans le SELECT ou des sous-requêtes, que le problème survient au SQLExec().
Si quelqu'un peut nous aider ce serait vraiment sympa. Inutile de nous dire de passer à Windev 22 ou de prendre la vieille libmysql.dll qui fonctionne. Des contraintes externes nous empêche de le faire. A la limite, s'il y a moyen "d'aiguiller" l’accès natif vers une libmysql.dll qui serait dans un autre répertoire que celui de l'exécutable, je prends.
J'ai essayé de modifier les formats de chaîne envoyés aux commandes sqlXXX() natives, peine perdue. Le fait que l'erreur retournée soit "00000" me fait penser qu'il y a erreur de l'accès natif et non de la DLL mySQL. Ma DLL WD120MSQL.dll est bien la dernière publiée par PCSoft.
Sinon, j'utilise une classe qui encapsule les appels à l'accès natif aussi m'est-il possible d'utiliser directement les fonctions de libmysql.dll ou le package .NET de MySQL. Mais ça me ferait bien (bip) d'être obligé d'en arriver là alors qu'il y a peut-être une solution à portée de main.
Merci de toute l'aide que vous pourrez m'apporter car c'est très pénible.Message modifié, 05 juillet 2017 - 14:39 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
3 messages |
|
Posté le 05 juillet 2017 - 19:08 |
Désolé pour le doublé. Il y a visiblement eu un problème de rafraîchissement. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
3 messages |
|
Posté le 05 juillet 2017 - 19:11 |
J'ai réussi à faire passer des trucs en jouant avec des AnsiVersUnicode() au moment d'envoyer la requête. Je pense que c'est ça. La DLL trop récente travaille en UNICODE et pas l'accès natif de Windev 12.
Existe-t-il un moyen de forcer l'accès natif de WD12 à travailler en UNICODE ?Message modifié, 05 juillet 2017 - 19:11 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
10 messages
Popularité : +1 (1 vote) |
|
Posté le 18 août 2017 - 14:59 |
Bonjour Francis,
Je ne sais pas si on parle du même sujet mais mon problème est le nombre de champ appelé dans mon select qui "plante" à partir de 8 champs ou plus.
Exemple : SELECT CHAMP1, CHAMP2, ... FROM MATABLE fonctionne jusqu'à 7 champs mais à partir du 8ème champs j'ai l'erreur :
Le contexte auquel cette requête fait référence (13156) est invalide (votre session s'est terminée pour une raison inconnue).
(59, ERR_BAD_CONTEXT_FOUND)
Attention je suis en WEBDEV (oui je sais sais pas le bon endroit mais erreur similaire)
Je me connecte à du MySQL et l'accès Natif est également en erreur.
Pour info, je suis aller dans le WDSQL (pour voir) et la version 64 bits est OK (je suis sur un PC Windows 10 64 bits) et le 32 bits est en erreur...
Bizarre, bizarre...
Comment as-tu fait Francis pour faire passer tes requêtes en Unicode ? |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
10 messages
Popularité : +1 (1 vote) |
|
Posté le 03 octobre 2017 - 11:09 |
Personn02 a écrit :
Bonjour Francis, Je ne sais pas si on parle du même sujet mais mon problème est le nombre de champ appelé dans mon select qui "plante" à partir de 8 champs ou plus. Exemple : SELECT CHAMP1, CHAMP2, ... FROM MATABLE fonctionne jusqu'à 7 champs mais à partir du 8ème champs j'ai l'erreur : Le contexte auquel cette requête fait référence (13156) est invalide (votre session s'est terminée pour une raison inconnue). (59, ERR_BAD_CONTEXT_FOUND) Attention je suis en WEBDEV (oui je sais sais pas le bon endroit mais erreur similaire) Je me connecte à du MySQL et l'accès Natif est également en erreur. Pour info, je suis aller dans le WDSQL (pour voir) et la version 64 bits est OK (je suis sur un PC Windows 10 64 bits) et le 32 bits est en erreur... Bizarre, bizarre... Comment as-tu fait Francis pour faire passer tes requêtes en Unicode ?
Bon le problème venait de mon PC et du windows qui était cassé...
Après réinstalle complète de windows tout est OK pour moi. |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|