Discussion :

[e.haefele]

Bonjour,

J'ai un problème que j'ai du mal à m'expliquer avec les fonctions HAttacheMémo et HExtraitMémo avec PostgreSQL. Ces deux fonctions ont l'air de fonctionner correctement mais lorsque j'utilise la fonction HExtraitMémo le contenu en retour est au format Héxadécimal.

Exemple simplifié :
J'enregistre un fichier texte qui contient "123", en retour dans mon fichier texte j'ai la valeur 'x313233'.

Pour y remédier je dois donc faire la chose suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SI HExtraitMémo ( TEST_BINAIRE, MonBinaire, sMonResultat ) ALORS
    sContenuHexa = fChargeTexte ( sMonResultat ) [[ 2 A ]]
    sContenu = HexaVersBuffer ( sContenuHexa )
FIN

Ma question est de savoir si une telle démarche vous parait normal où est-ce que quelque chose m'aurait échappé ? Ce qui me gène aussi c'est qu'actuellement je suis en version 16 et que la fonction HexaVersBuffer n'existe que depuis la 17.

Ce qui me surprend c'est qu'avec MySql je ne rencontre pas ce problème, je ne suis quand même pas le premier à faire ce genre de traitement avec PostgreSQL, ce n'est pas un bug ?

Dernières précisions, ma base de donnée a été créée avec pgadmin avec les paramètres par défaut donc avec un codage UTF8, et la connexion depuis windev est celle par défaut sans information étendues donc théoriquement compatible avec le codage UTF8.

Merci pour les précisions que vous pourriez m'apporter à ce sujet ...

[frenchsting]

As-tu regardé dans la doc de postgresql ? Je ne connais pas du tout, mais n'y aurait-il pas un paramètre qui fait que les champs bianires sont stockés en hexa ?

Sinon, dans l'analyse windev et l'aide de l'accès natif ?

[e.haefele]

As-tu regardé dans la doc de postgresql ? Je ne connais pas du tout, mais n'y aurait-il pas un paramètre qui fait que les champs bianires sont stockés en hexa ?

Je dois dire que je n'ai pas approfondie la documentation de postgresql mais même si elle indiquait une telle chose, ne serait-ce pas à l'accès natif de gérer cette contrainte. C'est dommage qu'on ait pas un retour d'expérience à ce niveau et je pense que je vais finir par envoyer un requête au ST.

Sinon, dans l'analyse windev et l'aide de l'accès natif ?

Elle par contre je l'ai lu en long et en large, elle n'indique rien du tout. Pour l'analyse j'ai essayé pas mal de choses et ça n'a rien donné de probant.

[Emmanuel Lecoester]

Emmanuel,

Voilà ce que je te propose :
Scénario 1 :
- insertion d'une ligne avec ton prog WinDev dans ta table PG
- lecture de la ligne avec un explorateur de bases de données PG

Que donne la donnée ? elle est au format héxa ou normal ?

Scénario 2 :
- insertion d'une ligne avec un explorateur de bases de données PG
- lecture de la ligne avec ton prog WinDev
- lecture avec un autre explorateur de bases de données PG

Que donnent les lectures ?

Si les deux OK c'est un pb accès natif en insertion. Si seule la lecture tierce est OK c'est que l'accès natif "transforme" ton champ ...

Emmanuel

[Hibernatus34]

Bonjour,

On dirait que vous essayez de lire un mémo binaire comme un mémo texte.
Vérifiez dans INFORMATION_SCHEMA.COLUMNS que le type de la colonne est de type TEXT ou NTEXT et pas IMAGE.
(NB. je ne connais pas du tout PostgreSQL, mais je regarderais d'abord ça sous SQL Server)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'LaTable' AND COLUMN_NAME = 'LaColonne'

Vérifiez aussi le type de la rubrique dans l'analyse, pour savoir aussi quel son de cloche a WinDev.

PS. Je viens de réaliser que dans le titre de votre message vous parlez de mémo binaire. Dans ce cas il faut le type IMAGE dans la base et mémo binaire dans l'analyse.

[e.haefele]

Bonjour,

On dirait que vous essayez de lire un mémo binaire comme un mémo texte.

Le texte c'était pour simplifier l'exemple mais c'est bien sur un mémo binaire que je veux travailler. J'y stocke des PDF ou des Images par exemple et depuis que j'applique la conversion Hexa, ces types de fichiers sont correctement reconnus alors que sans conversion ce n'était pas le cas.

Je vous remercie tous pour vos suggestions, fin de la semaine dernière j'ai envoyé une requête au ST, je vous tiendrai au courant dès qu'ils m'auront répondu.

[e.haefele]

Bonjour,

Je viens de recevoir aujourd'hui même la réponse du ST, pour eux tout est normal en version 78H. Malheureusement de mon côté j'ai refait le test en 78H et je constate toujours le même symptôme.

C'est assez incompréhensible car j'ai réalisé une batterie de test et j'ai systématiquement le même résultat.

J'ai positionné ci-joint un petit projet très simple (une fenêtre). Est-ce que quelqu'un parmi vous aurait l'occasion de réaliser le test ?

Protocole de reproduction :
Dans le code du bouton BTN_CONNEXION de la fenêtre FEN_TEST, il faut modifier les paramètres de connexion.

Ensuite il faut :
- Exécuter le projet
- Cliquer sur le bouton connexion qui crée également un fichier de test

Si la connexion est établie :
- Cliquer sur le bouton ajouter qui réalise le HattacheMémo
- Cliquer sur le bouton Lecture KO qui affiche le résultat en Héxa
- Cliquer sur le bouton Lecture OK qui affiche le résultat correct (123) mais qui passe par un fChargeTexte et un HexaVersBuffer

Pour le ST, le résultat est le suivant : Lecture_KO affiche "123", donc tout est normal !

Par avance je remercie celui ou celle qui aurait l'opportunité de réaliser ce test...

PS: La DLL pour l'accès natif est dans le répertoire exe du projet.

[madsland]

Bonjour,

J'ai fait votre test en WD17 69m avec PostgreSQL 9.1.4 et j'ai exactement le même problème, même résultat en WD14.

J'ai ensuite installé PostgreSQL 8.4.12 et là plus de problème que ce soit en WD14 ou WD17.

Je ne sais pas ce que donne la 9.0.8, si vous avez le courage ...
De toute façon il est fort probable que le ST n'était pas sur la même version que vous.

Il ne vous reste plus qu'à renvoyer un mail au ST.

Cordialement

Madsl@nD

[e.haefele]

Bonjour,

J'ai fait votre test en WD17 69m avec PostgreSQL 9.1.4 et j'ai exactement le même problème, même résultat en WD14.

J'ai ensuite installé PostgreSQL 8.4.12 et là plus de problème que ce soit en WD14 ou WD17.

Merci beaucoup pour cette précision, au départ je n'avais pas pensé à faire le test avec d'autres versions de PostgreSQL mais c'est vrai que si le ST n'était pas en phase avec moi, il était très judicieux de tester une version plus ancienne.

Je ne sais pas ce que donne la 9.0.8, si vous avez le courage ...
De toute façon il est fort probable que le ST n'était pas sur la même version que vous.

Il ne vous reste plus qu'à renvoyer un mail au ST.

Je vais leur envoyer un mail dès demain, concernant le test avec la 9.0.8, si le ST est intéressé par le résultat, je le ferai.

En tout les cas merci pour tout !

[hpascal]

Bonjour

Pour ma part test KO en 9.0.4

[e.haefele]

Bonjour,

Avec votre aide le ST a finalement pu référencer l'incident et il est donc plus que probable qu'un correction sera apportée à plus ou moins brève échéance.

Dans l'attente du correctif que je ne manquerai pas de vous signaler, je clos cette discussion.

Merci à tous !

[e.haefele]

Bonjour,

Le ST m'indique ce jour que le problème venait en fait de la dll libpq.dll qui est fournie avec l'Accès Natif PostgreSQL. Manque de chance, cette dll est en version 7.4.23 de PostgreSQL et n'était plus compatible avec la version 9 ou tout du moins pour la partie encodage des binaires.

Donc pour régler le problème il suffit d'utiliser la dll libpq.dll de la version 9 et tout revient dans l'ordre. En utilisant cette méthode, j'ai cependant dû également récuper ses dépendances, à savoir les dll suivantes : libintl-8.dll, libiconv-2.dll.

J'en profite aussi ici pour remercier le ST qui a été très réactif sur ce sujet et d'autres, ce qui m'a agréablement surpris ces derniers temps.