Discussion :

[GrPtj]

Serveur linux :
Firebird-3.0.4.33054-0.amd64 sous CentOS 7
champ Texte: BLOB SUB_TYPE 1 SEGMENT SIZE 80 CHARACTER SET NONE
Client windows :
Firebird-3.0.4.33054_0_x64.exe sous Windows 10
Delphi Rio 10.3.1, application VCL windows.
Bdd lues par un connecteur firedac TDBConnection, driver fb
composant TDBMemo lié au champ TEXTE d’une table firedac
Problème:
blob lu avec IBExpert sans problème (plusieurs lignes accents et caractères spéciaux)
blob lu dans le memo: seulement la première lettre

En local sur le poste, pas de problème
client et serveur: Firebird-3.0.4.33054_0_x64.exe sous Windows 10
blob lu avec IBExpert = blob lu dans le memo

Auriez vous une idée de ce qui ne va pas ?
Cela peut-il venir d'une dll ?

[SergioMaster]

Bonjour,

je n'ai pas pu faire un test complet par manque de moyen (pas de Firebird serveur sur LINUX sous la main)
une DLL c'est possible IBExpert utilisant sa propre copie de fbclient.
un test infaillible, copier fbclient.dll (bonne version, bon nombre de bits en fonction du programme cela va de soi) dans le répertoire de l'application
Attention en mode debug c'est une version 32 bits

[GrPtj]

Bonjour, je reprends seulement ayant du m'absenter …
Merci pour la réponse, mettre la dll windows dans le répertoire de l'application ne change rien.
j'ai essayé avec C:\Program Files\Firebird\Firebird_3_0\WOW64\fbclient.dll
et aussi avec C:\Program Files\Firebird\Firebird_3_0\fbclient.dll qui est, je pense, la dll pour 32 bits ?
Le serveur firebird étant en linux ce n'est probablement pas celles qu'il me faut.
le serveur firebird utilise /usr/lib/libfbclient.so.3.0.4 installée avec le serveur
je ne vois pas de version 3 dans /usr/lib/
or delphi, installé en 32 bits, doit chercher dans /usr/lib / ?

[SergioMaster]

Bonjour,

j'ai essayé avec C:\Program Files\Firebird\Firebird_3_0\WOW64\fbclient.dll
et aussi avec C:\Program Files\Firebird\Firebird_3_0\fbclient.dll qui est, je pense, la dll pour 32 bits ?

Non c'est l'inverse, wow64 indique que c'est une bibliothèque à émuler en 64 bits ainsi en a décidé Deus Microsoft
Et ce n'est pas côté serveur Firebird qu'il faut faire quoique ce soit mais bien du côté poste de développement
En mode design c'est la dll 32 bits qui est utilisée (donc celle dans syswow64) en mode exécution du programme c'est selon la version du programme et donc de la compilation Delphi.

je n'ai pas pu faire un test complet par manque de moyen (pas de Firebird serveur sur LINUX sous la main)

Mes moyens ont évolués et après quelques galères dues à mon firebird.conf sous linux cf cette discussion dès que j'ai le temps je ferai un petit test

[GrPtj]

En mode design c'est la dll 32 bits qui est utilisée (donc celle dans syswow64) en mode exécution du programme c'est selon la version du programme et donc de la compilation Delphi.

Du coup c'est assez étrange que je n'ai pas de problème en local et seulement sur le linux distant.

-en debug, fbclient de syswow64, lecture du blob ok
-poste windows et firebird en 64, mais delphi installé en 32, du coup mon application s'exécute en 32 non ?
pour l'exe sur mon poste Windows pointant sur le firebird de ce même poste, lecture du blob ok

-pour l'exe sur mon poste Windows pointant sur le firebird am64 du serveur sous CentOs, lecture du blob -> Seule la première lettre lue ...

[alanglet]

Bonjour,

La version de fbclient.dll à utiliser doit toujours correspondre à la version 32b ou 64b de votre exécutable, indifféremment de la version du serveur (qu'il soit Windows ou Linux). Le seul cas où le serveur doit être de la même version que l'exécutable, c'est si vous utilisez Firebird embedded.
Par contre votre problème peut provenir d'un mauvais choix de jeu de caractères de connexion: il est préférable de choisir celui utilisé en interne par votre exécutable. Sous D7 j'utilise WIN1252, sous Lazarus UTF8. Mais toujours se rappeler que le serveur ne fait le transcodage que si les jeux de caractères de connexion et de codage dans le champ de la base sont différents, émettant une erreur en refusant les caractères appartenant à un seul des 2 jeux. Par contre si les 2 jeux sont identiques le serveur ne fait aucun contrôle, autorisant l'écriture de caractères inexistants dans le jeu utilisé dans le champ. La base peut alors devenir inutilisable depuis un logiciel utilisant un jeu de caractères de connexion différent.

André

[SergioMaster]

Bonjour,

J'ai pris le temps de faire le test. AMHA le problème se situe dans votre programme
ces deux images écrans pour le prouver, la base de données (la classique employee.fdb) est sur mon poste Ubuntu
VCL

FMX

[GrPtj]

Merci d'avoir pris le temps de tester.
je résume la question :
1. sur un poste windows 10 avec Firebird-3.0.4.33054_0_x64, les blobs sont mal lus depuis une appli avec connexion firedac compilée en win32
quand la Bdd se trouve sur le même poste
2. sur un poste windows 10 avec Firebird-3.0.4.33054_0_x64, les blobs sont mal lus depuis une appli avec connexion firedac compilée en win32
quand la Bdd se trouve sur un poste CentOs 7 avec Firebird-3.0.4.33054-0.amd64

D'après les réponses précédentes :
- On exclut le problème de versions windows/linux.
- On exclut le problème de dll car la même dll est utilisée dans les 2 cas.

Du coup peut il y avoir un problème de jeu de caractère ?
La base locale est un backup/restaure de la base distante donc même paramètres je pense.
Le connecteur firedac est le même donc même paramètres. J'ai essayé CharacterSet=UTF8 et CharacterSet=NONE, cela ne change pas la lecture du blob.

Je ne vois pas trop où chercher ...

[SergioMaster]

Essayez comme moi avec un simple programme se connectant sur employee, je n'ai même pas eu besoin de compiler pour vérifier

[GrPtj]

je ne vois pas le dossier d'exemple avec la table employee dans mon install ...

[GrPtj]

je vous prie de m'excuser, je cherchais dans embarcadero
je continue mes tests lundi.

[GrPtj]

Bonjour, j'ai repris avec succès mes recherches avec la base employee comme préconisé
nouveau projet / connexion sur employee -> ok
nouveau projet / connexion sur MaTable -> ok
Pour les caractère accentués :
Mon projet / connexion sur employee -> ok, il y avait une modif du CharacterSet qui trainait dans la suite du code
> Il me reste une question: pourquoi la définition du characterSet ne posait-elle pas de problème en local ?
probablement est-ce l'explication de Alanglet : se rappeler que le serveur ne fait le transcodage que si les jeux de caractères de connexion et de codage dans le champ de la base sont différents ?

Pour le fait de n'afficher que la première lettre du blob :
pb causé par le champ à afficher de type ftmemo avec displaywidth = 10
résolu en supprimant les champs définis dans la requête.
> Il me reste donc une question: De quel type le champ devrait-il être pour qu'il soit lu correctement, dans un cas où la définition des champs dans la requête serait nécessaire ? j'ai essayé sans plus de succès ftwidememo.

Merci pour votre aide