Login mot de passe
forum - Tous les messages
   Tous les messages (Bugnet)

 Bas   Précédent   Suivant

(1) 2 3 4 ... 9 »


#1 Re: Crash si ajout instance de php4wd ou de sqlmanagerx dans les expressions du débogeur
Bugnet Posté le : 2018/4/30 16:58
Bonjour,

Je peux clore ce topic, j'ai fini par trouver l'origine du crash.

J'avais il y a longtemps dans l'explorateur de projet, dans la classe PHP4WD, dans la partie propriétés, ajouté une nouvelle propriété d'un type un peu particulier car son icône était le même que celui de la ligne "Propriétés" (un cube vert avec un point rouge). Aucun idée de la manière dont j'étais arrivé à ce résultat. Je lui avais d'autre part ajouté une routine d'initialisation, avec un code vide.
Je ne me suis jamais servi de cette propriété et l'avais laissée la, pour un usage hypothétique futur.

Il m'a suffit de supprimer cette propriété ainsi que sa routine d'initialisation,, pour que le crash du debug disparaisse complétement.

Je peux enfin programmer avec le confort du débogueur...

Crdlt
Franck


#2 Re: Plus de code dans mySQLTable ??
Bugnet Posté le : 2018/4/27 18:32
J'essaie de démêler tout ça.
En particulier, avec ma version de la classe, comm edéjà indiqué je ne peux plus utiliser le debug, ca plante tout. J'essaie de corriger ça avant de t'envoyer une proposition de code.

Au passage, il me semble qu'il y a une erreur ligne 27 de MySQLLitMemo :

SI :CryptRetour ALORS v_ligne = :URLDecrypte(v_ligne)
SI :dataHexa ALORS v_ligne = HexaVersBuffer(v_ligne)
SI :modeUTF8 = Vrai ALORS myBuffer = TF8VersChaîne(myBuffer)
v_ligne = myBuffer
fSauveTexte(fileName,v_ligne)

soit v_ligne = myBuffer fait partie de la condition sur uTF8 (Manque un FIN), soit il n'a rien à faire la.

Crdlt
Franck


#3 Re: Plus de code dans mySQLTable ??
Bugnet Posté le : 2018/4/27 16:42
Ok Merci Firetox,

Je vois aussi que mySQLCol n'existe plus. J'imagine qu'il faut utiliser à présent mySQLColLong pour être compatible avec l'Unicode qui peut coder sur les caractères sur 3 digits ?

Autre sujet, mais apparenté :
Cela fait plusieurs années que j'avais adapté la classe pour gérer les applis 100% unicode. Je pourrais à présent virer toutes mes modifs et repartir sur ta classe plus récente, puisque tu as fait le même travail. Sauf que je vois que tu n'as pas modifié les codes de cryptage et de décryptage. Or, de mon expérience, il ne fonctionnait pas sur des caractères codés sur 3 octets. J'avais du en faire une version spéciale pour l'unicode.

Ma seconde question est donc toute bête: ce code fonctionne t'il chez tout le monde, sur les bases en UT8/unicode, avec le mode crypté à vrai ??

Si la répons est non, je propose alors de soumettre les modifs que j'avais apporté au codes de cryptage et décryptage (aussi bien du coté de la classe WD que coté PHP d'ailleurs).

Crdlt
Franck


#4 Plus de code dans mySQLTable ??
Bugnet Posté le : 2018/4/27 16:02
Bonjour,

Je suis en train de comparer le code de la dernière version de la classe c_PHP4WX avec celle d'un de mes projets, utilisant une ancienne version de c_PHP4WD largement modifiée au fil du temps pour mon usage, afin de rattraper le retard.

Et je découvre que la procédure mySQLTable ne fait plus rien :


PROCÉDURE mySQLTable
(requestNumbertableName)

LOCAL
    tmpBuffer     est une chaîne
    numFields     est un entier
    
myRequestNumber est un entier


Toute la suite du code est mis en remarque.

Je pige pas. C'est une erreur ou cette procédure est obsolète ?? remplacée par quoi ?

Comme je m'en sert pas mal dans ce projet, j'ai vraiment besoin de comprendre ce que j'ai loupé.

Je vois aussi que mySQLCol n'existe plus. Il faut utiliser mySQLColLong à la place ?

Crdlt
Franck


#5 Re: Compatibilité PHP4WD et PHP7
Bugnet Posté le : 2018/4/26 17:57
Si qcq d'autre rencontre le même soucis : cela venait de la configuration PHP du compte : nd-mysqli était activé à la place de mysqli.

Crdlt
Franck


#6 Crash si ajout instance de php4wd ou de sqlmanagerx dans les expressions du débogeur
Bugnet Posté le : 2018/3/29 19:25
Bonjour,

Depuis de très nombreux mois je ne pouvais plus utiliser le débuggeur Windev, car cela générait systématiquement quelque soit l'endroit dans le code de mon projet ou je plaçais un point d'arrêt, un plantage du type :

Module : wd230vm64.dll
Version du module : 23.0.222.4
VI : 01F230042u
Adresse de base : 0000000060790000
Erreur systeme : Access violation (GPF)
RIP = 0000000060890EA2
OS : Windows 7 x64 Service Pack 1(6.1.7601)

Pensant à un gros bug de Windev 20 que j'utilisais, j'ai acheté la mise à jour WD23, pour constater que ça ne changeait rien. Mais du coup j'ai pu avant hier ouvrir un ticket de support chez PCSoft et ils m'ont aidé à mettre la main sur l'origine (pas la cause) du problème.

Le plantage est causé par la présence dans la liste des expressions du débogueur, soit de mon instance de php4wd, soit d'une instance d'un des objets SQLManagerX (qui utilisent mon objet php4wd).

Si je supprime tous ces objets de la liste des expressions du débogueur, le débogueur marche bien.
Mais ça limite les possibilité de debug du coup. Je ne peux plus voir le résultat des requêtes par exemple.

Quelqu'un a t'il déjà eu ce soucis et trouvé la solution ?

Crdlt
Franck


#7 Compatibilité PHP4WD et PHP7
Bugnet Posté le : 2018/3/28 19:15
Bonjour,

Sur un projet Windev j'utilise une version assez ancienne de PHP4WD.PHP car je l'ai tellement modifiée pour des raisons perso que la version 9 ne peux pas fonctionner en l'état.

Un de mes clients vient de passer sa version PHP de 5.6 à 7.0, et depuis mon appli n'arrive plus à se connecter.

Quand je test php4wd.php?test=OUI, le navigateur affiche ce message d'erreur:

Citation :
Service Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.



Interrogé, l'hébergeur me dit que ce script n'est pas compatible PHP7.
En cherchant sur ce forum j'ai pu comprendre que la version 9 est compatible PHP7.
Mais j'ai beau comparer mon ancienne version et la 9, je ne vois pas trop ce que je dois changer ou ajouter pour qu'elle fonctionne sur PHP7.

Une idée ?

EDIT qcq heures plus tard : Je viens d'upgrader le PHP de mon mac de 5.6 en 7.0 pour débuger cette affaire, et je m'aperçois que mon appli se connecte très bien. PH4WD.PHP n'a pas bronché.

Donc le problème est spécifique à l'hébergeur de mon client (qui en l'occurrence est aussi le mien), et uniquement lorsque PHP est configuré en 7.0.

Ca va pas être facile à résoudre cette affaire...

Crdlt
Franck


#8 Re: Procédure stockée
Bugnet Posté le : 2017/7/16 11:27
Bonjour,

J'ai trouvé pour la 1ere question : en l'état, la classe ne supporte pas le CREATE des les procédures stockées, et ce n'est pas un problème d'injection comme je l'ai d'abord cru.

C'est simplement le "decoupe_chaine" de connect.php qui découpe ce qui se trouve entre le BEGIN et le END des procédures stockées, à chaque ;.

Je m'en suis sorti en modifiant le code de mes procédures stockées et la classe pour différencier les "vrai" ; de ceux présents entre BEGIN et END.

Pas hyper propre mais ça semble marcher.

Note:
Les fonctions DROP et CALL fonctionnent très bien dans un mySQLExec().
Du coup de ne vois pas trop à quoi servent la fonction mySQLExecPS et les fonctions bind associées.


Je reste par contre sans réponse concernant ma seconde question, la version 9 de la classe fonctionne t'elle avec une appli tout UNICODE ?


Crdlt
Franck


#9 Procédure stockée
Bugnet Posté le : 2017/7/15 14:17
Bonjour,

MySQL 5 a introduit la notion de procédures stockées. Les classes SQLManagerX et PHP4WD supportent t'elles son utilisation ? Plus précisément, peut-on créer la procédure interne à partir de ces classes ?

Lorsque j'essaie de faire un mySQLExec d'une requête de ce type : "CREATE PROCEDURE nom_procedure (mes variables) BEGIN code_sql_de_ma_procédure END", j'ai systématiquement une erreur SQL du type syntaxe erreur sur ''.
(code qui fonctionne si exécuté depuis PHPMyAdmin)

D'après ce que je comprends, il s'agirait d'un problème d'injection SQL.
J'ai essayé mais ça ne marche pas , de mettre mon code (code_sql_de_ma_procédure) entre guillemets, ou dans une variable.

Par contre l'utilisation de requêtes préparées (avec PREPARE et EXECUTE) fonctionnent bien.
Mais dans mon cas j'ai besoin de passer par une procédure car ma requête contient plusieurs requêtes séparées par des ; , ce qui n'est pas supporté par les requêtes préparées.

Il y a t'il une astuce à connaitre ? une histoire de magic-quote ? je tourne autour depuis des heures sans trouver la bonne méthode.

Autre question : je me dis que le problème vient peut être de mes fichiers PHP4WD.PHP et CONNECT.PHP qui sont en gros les version 7.x, largement modifiés par moi même pour fonctionner avec une appli entièrement UNICODE. Et qu'il faudrait peut être que je migre sur la version 9 de la classe. Dans la doc, il est écrit que cette version support les alphabet arabe chinois etc... masi en analysant son code, je ne vosi rien qui me laisse penser qu'elle sait travailler sur les chaines en UNICODE, en particulier au niveau des fonction de cryptage et décryptage.
Donc ma question est " est ce que la version 9 de la classe accès natif PHP4WD est faite pour fonctionner avec des chaines en UNICODE ? (pour rappel, en UNICODE, chaque caractère est codé sur 2 ou 3 octets au lieu de 1 seul en ANSI)

Merci d'avance pour vos réponses à ces deux questions.

Crdlt
Franck


#10 Re: Correctifs pour PDO
Bugnet Posté le : 2016/10/20 10:52
Aucun soucis, il manquerait plus qu'on t'en veuille avec tout le boulot que tu fais pour nous gracieusement.

De mon coté j'ai au fil des années fais tellement de modifs dans les classes et les scripts pour les adapter à des besoins spécifiques, que je ne peux plus me contenter de re-télécharger et de remplacer les fichiers. Je suis obliger de comparer les codes des nouvelles versions avec mon propre code et de l'adapter si nécessaire. Juste le résultat d'un manque de rigueur.
Un jour, si je trouve le temps, je repartirai de la version officielle et adapterai le code des applis pour qu'elles soient directement compatibles et avoir ainsi une maintenance plus simple.

En tous cas c'est vraiment la classe SQLManagerX

Crdlt
Franck



 Haut
(1) 2 3 4 ... 9 »