DB Firebird - Fonction inconnue à partir d'une application Delphi.

Bonjour,
Le problème de Flamerobin avec les charsets et l'affichage des données a toujours été plus ou moins présent (c'est un de ses points gris)

Citation:

---

Anecdotiquement, voici le message Warning lors de la connexion de la base de données depuis l'utilisation de Flamerobin :
Database charset: WIN1252 is different from connection charset: UTF8.

---

c'est loin d'être une anecdote, puisque c'est probablement la cause de cet affichage "défectueux", c'est très facile à corriger puisqu'il faut simplement changer les propriétés de la connexion.

Toutefois, étant donné que vous mixez différent charsets (NONE) et WIN1252 pour le moins, vous risquez malgré tout d'avoir quelques petit affichages délicats.
Je me suis échiné à expliquer ce point lors d'une discussion sur le CHARSET ISO8859_1 de firebird ne correspondant pas à la norme ISO8859-1 mais ISO8859-15, les développeurs de Flamerobin, eux aussi, utilisent la norme ISO8859-1 pour l'affichage et non ISO8859-15 d'où par exemple le problème du €
c'est pour cela que, si cela reste windows, je préconise le Win1252

un chose me fait tiquer toutefois : le fait que vous deviez utiliser lower et non LOWER (ou toute casse possible). Normalement, comme SELECT ou tout autre terme un nom de fonction est insensible à la casse, sauf si : le nom de la fonction est déclarée entre guillemets ou apostrophes :koi:

Bonjour,
Pour la première fois, Delphi exécute et recupère les résultats de la procédure Field_From_Substr.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

With CadaDataModule.ZQuery.Sql do begin Clear; Text := 'SELECT NOM FROM field_from_substr(' + QuotedStr('"TableProprio"') + ', ' + QuotedStr('NOM') + ', ' + QuotedStr('aryl') + ');' end; CadaDataModule.ZQuery.ExecSql; CadaDataModule.ZQuery.Open; For i := 0 to CadaDataModule.ZQuery.RecordCount - 1 do begin TmpStr := TmpStr + CadaDataModule.ZQuery.FieldByName('NOM').AsString + #10; CadaDataModule.ZQuery.Next; end; ShowMessage(TmpStr);

---

Pièce jointe 370918
Reste le problème des caractères accentués que je ne comprends pas parce qu'une requête simple sur la même table n'a pas cette conséquence.
J'ai tenté de modifier ma procédure par un collate mais quel que soit le jeu de caractère, j'ai la même erreur à la compilation de la première instruction où le collate est rencontré.

Code:

---

S=lower(:StrSubStr COLLATE UTF-8);

---

Citation:

---

Preparing query:
CREATE PROCEDURE FIELD_FROM_SUBSTR (
TABLENAME Char(31),
FIELDNAME Char(31),
STRSUBSTR Varchar(255) )
RETURNS (
NOM Varchar(255) )
AS
DECLARE VARIABLE S VARCHAR(32);
DECLARE VARIABLE STMT VARCHAR(1024);
BEGIN
S=lower(:StrSubStr COLLATE UTF-8);
STMT='SELECT '||FieldName||' FROM '||TableName||' WHERE lower('||FieldName||') LIKE ''%'||S||'%''';
FOR EXECUTE STATEMENT STMT INTO :NOM
DO SUSPEND;
END
Error: *** IBPP::SQLException ***
Context: Statement::Prepare(
CREATE PROCEDURE FIELD_FROM_SUBSTR (
TABLENAME Char(31),
FIELDNAME Char(31),
STRSUBSTR Varchar(255) )
RETURNS (
NOM Varchar(255) )
AS
DECLARE VARIABLE S VARCHAR(32);
DECLARE VARIABLE STMT VARCHAR(1024);
BEGIN
S=lower(:StrSubStr COLLATE UTF-8);
STMT='SELECT '||FieldName||' FROM '||TableName||' WHERE lower('||FieldName||') LIKE ''%'||S||'%''';
FOR EXECUTE STATEMENT STMT INTO :NOM
DO SUSPEND;
END )
Message: isc_dsql_prepare failed

SQL Message : -204
Undefined name

Engine Code : 335544569
Engine Message :
Dynamic SQL Error
SQL error code = -204
Data type unknown
COLLATION UTF is not defined

---

Si la chaine de recherche comporte un caractère accentué
C'est la fenêtre "fatale"

Citation:

---

SELECT NOM FROM field_from_substr('"TableProprio"', 'NOM', 'arylè')

---

Pièce jointe 370934

Bonjour,

Pour ce qui est du COLLATE c'est niet, un COLLATE ne change pas le CHARSET, c'est plus un ordre de tri à l'intérieur d'un CHARSET
le fait que les colonnes incriminées soit en CHARSET NONE, implique aucun COLLATE applicable

Bonjour,
J'ai créé une base de données vide en UTF8 avec la même structure que celle posant problème.
Je trouve sur le net plusieurs logiciels de copie des données des tables d'une base de données à une autre.
Quelle est celui que vous préconisez ?
Merci d'avance.

Bonjour,

Citation:

---

Je trouve sur le net plusieurs logiciels de copie des données des tables d'une base de données à une autre.
Quel est celui que vous préconisez ?

---

à vrai dire aucun ne m'a satisfait, il ont chacun leurs points forts mais aussi points faibles.
La plupart pêche surtout sur les blobs, seul ibexpert version payante semble avoir toutes les options, encore que je ne sais ce qu'il en est au niveau des passages entre charsets différents

Bonjour,
Ma base de données ne contient pas de blob.

Après création des tables avec FlameRobin et remplissage avec FbCopy qui est vraiment pratique et rapide, je constate que les erreurs subsistent.
La base de données est bien en UTF8 par défaut.
A l'ouverture je suis prévenu que c'est le cas mais que ce jeu de caractère est différent de la connexion (NONE).
Je vérifie les DDL de création des tables et je constate que «CHARACTER SET UNICODE_FSS» a été ajouté à chaque champs.
Je constate que UTF8 n'est pas repris dans RDB$CHARACTER_SET_NAME.

Comment est-ce possible alors que la base de données peut-être créée avec ce jeu de caractères par défaut. C'est exactement la même anomalie qu'en FbExpert.
Je crois me souvenir avoir lu que Firebird peut problème avec UTF8 et qu'il est conseillé d'utiliser ISO8859_1.
Devrais-je recréer la base de données et les tables avec ce jeu de caractères ?

Bonjour,

à ce sujet, je vous ai déjà écrit que fb 1.5 ne connaissait pas UTF8 mais UNICODE FSS ce qui n'est pas tout à fait la même chose.
Que si vous vouliez utilisez un charset ISO8859_1 correspondant de fait à la norme ISO8859-15 pouvait être utilisé, mais aussi WIN1252 , Delphi 6 n'étant pas unicode je vous conseille cette dernière option.

Il me semble que j'avais diagnostiqué que votre base était déjà en Win1252 mais que, malheureusement, la fameuse colonne NOM était elle en CHARSET NONE je ne sais pour quelle raison !

Citation:

---

Envoyé par defluc

Il y a effectivement des choses contradictoires pour ce qui est du jeu de caractères.
Bizarre également, la liste de choix du jeu de caractère ne comporte pas UTF8, raison pour laquelle j'avais sélectionné None pour le champs Nom. J'ai essayé ISO8859_1 mais cela ne change pas le résultat.

---

Il faut vraiment que vous arriviez à comprendre cette notion de CHARSET, COLLATE et de version Firebird avec les tableaux contenu dans les notes de release.

Franchement passez à une version supérieure de firebird (en triturant les sources de ZEOSDBO puisque D6 n'est pas compatible avec la version 7, ce doit être possible!)
2.1 serait l'option la plus intéressante et sans effort car je note que la version 6.6 propose jusqu'à la version 2.1 de firebird puisque je vois dans les sources \plain\zplainfirebird21.pas
mais aussi dans ZdbcInterbase6.pas

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

function TZInterbase6Driver.GetSupportedProtocols: TStringDynArray; begin SetLength(Result, 9); Result[0] := 'interbase-5'; Result[1] := 'interbase-6'; Result[2] := 'firebird-1.0'; Result[3] := 'firebird-1.5'; Result[4] := 'firebird-2.0'; Result[5] := 'firebird-2.1'; // embedded drivers Result[6] := 'firebirdd-1.5'; Result[7] := 'firebirdd-2.0'; Result[8] := 'firebirdd-2.1';   end;

---

donc vous pouvez déjà migré vers 2.1

Citation:

---

je constate que les erreurs subsistent , La base de données est bien en UTF8 par défaut.

---

je m'étonne, si vous êtes resté en FB1.5, de votre assertion !
avec Flamerobin, cliquez sur l'alias et choisissez propriétés pour vérifier les "database infos"

Citation:

---

A l'ouverture je suis prévenu que c'est le cas mais que ce jeu de caractère est différent de la connexion (NONE).

---

mais cela, il suffit de l'indiquer dans la propriété de connexion "database registration info"
toujours alias de base, non connectée, clic avec le bouton droit on obtient le menu contextuel qui permet de modifier le charset de connexion


En dernière remarque, je ne suis pas sur que FBCopy travaille correctement le changement de charset, l'outil à utiliser pour ça aurait plutôt été fbclone

Bonjour,
Je vous remercie beaucoup pour vos éclaircissements dont j'avais certains bien en tête.
C'est d'ailleurs la raison pour laquelle j'ai passé ma journée d'hier à me documenter pour migrer vers une version plus récente ou plutôt moins ancienne :) de Firebird.
Cela nécessite également une installation de composants Zeos qui "connaissent" Firebird > 1.5 et compatibles avec Delphi 4. J'ai mis un temps fou pour identifier la version des composants actuellement installés. C'est la 6.1.5-stable build at 2004-04-29 07:03:04 suivant le fichier Version.
Toutes celles que j'ai trouvées > 6.1, ne sont compatibles qu'à partir de Delphi 5.
https://sourceforge.net/projects/zeo...es%2FOldFiles/J'ai malgré tout essayé d'installer la 6.6.6 mais en pure perte.
Je suis donc gros Jean comme devant et je pense que je vais en rester là parce que je ne me vois pas réécrire une si grosse application sous Lazarus par exemple vers lequel j'ai tenté une conversion qui s'est soldée par de nombreuses erreurs impossibles à maitriser. C'est mon ancien client qui va être dépité.:pleure:

Citation:

---

Trouvé : la version zeosdbo-6.1.5-stable.zip est la seule version qui est à la fois compatible Delphi4 et contient le composant ZTable (c'est la première version avec ZTable dedans et en même temps la dernière à proposer le dossier Delphi4 ! je l'ai échapée belle )

---

Confirmation de Harry

Pour avoir quand même fait quelques migrations de programmes D3 vers D7, D7 vers D2010 et même quelques D3 (BDE) vers Tokyo (Firedac) c'est quand même du domaine du possible sans trop de pénalités de temps.
Si je ne migre pas mon application totale de D3 à Tokyo c'est plus une question de changement de style d'écriture de mes programmes, d'optimisation de mes accès aux données et surtout des nouvelles possibilités offertes !

Citation:

---

avec Delphi 4.

---

pourquoi étais-je persuadé qu'il s'agissait de D6 :koi:

De toute façon vous êtes confronté à deux problèmes différents que vous fusionnez
1- le problème Firebird avec le charset à NONE de vos champs de recherche
2- le problème ZEOSDBO restreignant les versions de Firebird utilisables

le 1 peut se régler en produisant un copie de base avec des colonnes de bon charset (a mon avis WIN1252 et ce à cause de la version non unicode de Delphi)
la recherche peut aussi être améliorée par l'ajout d'UDF "externes" tel celles contenues dans FreeAdHocUDF

le 2 est plus pénalisant, la version 6.1 est a mon avis pas exempte de bugs ou, à tout le moins, de non prise en charge de certaines fonctionnalités qu'il serait nécessaire d'avoir

J'insiste sur le Win1252 et non d'autres charset , UTF8 ne pourra pas fonctionner avec une version non unicode de Delphi, win1252 couvre quand même les caractères occidentaux (sens large du terme qui recouvre la plupart des langues européennes sauf cyrillique)

Bonjour,
La base de données et les tables ont été recréées et remplies en WIN1252.
Sous Flamerobin tout baigne, affichage des caractères accentués et exécution de la procédure Field_From_Substr.
Par contre, sous Delphi 4, l'affichage des caractères spéciaux est foireux dans un TDbgrid de test et l'exécution de la procédure génère le message

Citation:

---

Cannot transliterate character between character sets.

---

Pour la migration Delphi/Lazarus, le problème, c'est moins le code que les fiches. J'en ai 20 dont certaines avec 281 composants dans 7 pages à onglets.
Voir https://www.developpez.net/forums/d1...projet-delphi/
Sans compter que sous Lazarus, j'ai tout à apprendre.

Là ça touche plus la partie ZEOSDBO
peut être en jouant sur la partie properties de la connexion ? mais l'encodage est un thème que je n'ai pas abordé dans mon tutoriel sur les ZEOSDBO toujours en brouillon même si accessible (le chapitre est prévu). En premier lieu tentez d'ajouter codepage=WIN1252, mais cette propriété m'a fait douter alors que je rédigeai ce brouillon (pour preuve j'indique que cela jouait aussi sur les messages ...il y a aussi la propriété lc_ctype=WIN1252 à tester en leu et place de codepage mais là, il faut fouiller dans les sources de zeosdbo (merci gexpert et son grepsearch) pour être sûr qu'il existe !

Citation:

---

Pour la migration Delphi/Lazarus, le problème, c'est moins le code que les fiches. J'en ai 20 dont certaines avec 281 composants dans 7 pages à onglets.
...
Sans compter que sous Lazarus, j'ai tout à apprendre.

---

je n'ai parlé que de migration entre versions de Delphi, j'ai déjà tenté quelques migrations de Delphi vers Lazarus mais à partir d'un D7 (clx qui plus est), je rappelle que Lazarus est un fork de Delphi 7 qui fut un temps open source. Passer d'un D4 à Lazarus sans passer par la case D7 me parait du travail d'équilibriste, de plus dés qu'il y a composant tiers

Citation:

---

Dbchart, chart, Series, Teeprocs et TeEngine.

---

cela devient encore plus complexe.

J'aime bien Lazarus comme on aime une voiture de collection, tant qu'on a pas peur et le temps de mettre les mains dans le cambouis, dans le cas de Lazarus, porter des composants c'est assez génial mais quand on est encore en "environnement entreprise" c'est loin d'être compatible avec des objectifs de productivité. Je vais certainement fâcher des lecteurs si je dit que Lazarus n'est qu'un hommage (appuyé) à Delphi 7 mais pas ce dernier en ce qui concerne les ressources disponibles, en excuse cela fait longtemps que je n'ai pas remis le nez dedans et j'ai pariè sur les "nouvelles" approches des dernières versions de Delphi (FMX et Livebindings)

Moi je conseillerais une migration D7, voire même une version D2007+ permettant l'unicode. S'il n'y a pas de composants tiers autre que ZEOSDBO, je me demande même si la dernière version Starter ne pourrait pas fonctionner ! En tout cas zeosdbo fonctionne sur cette version (cf. mon dernier tutoriel) pour ce qui est de DBChart chart etc.. je pense qu'il faut aller voir du côté de chez Steema Software car je ne les vois pas en GetIt

Affichage résolu sous Delphi grâce au code

Code:

---

1 2	CadaDataModule.ZConnection.Properties.Values['codepage']:='win1252'; CadaDataModule.ZConnection.Connect;;

---

A noter que le code suivant trouvé sur le net qui ne provoque aucune erreur de compilation est sans effet sur les caractères accentués qui restent erronément affichés :

Code:

---

1 2	CadaDataModule.ZConnection.Properties.Add('codepage=win1252'); CadaDataModule.ZConnection.Connect;

---

Seconde victoire pour ce qui est de l'exécution de la procédure Field_From_Substr avec le code

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

procedure TMainForm.Test2Click(Sender: TObject); Var TmpStr : String; i : Integer; begin with ZStoredProc do begin StoredProcName := 'Field_From_Substr'; ParamByName('TableName').Value :='"TableProprio"'; ParamByName('FieldName').Value :='NOM'; ParamByName('StrSubstr').Value :='rylè'; Open; end; TmpStr := IntToStr(ZStoredProc.RecordCount) + ' enregistrements trouvés'; ZStoredProc.First; For i := 1 to ZStoredProc.RecordCount do begin TmpStr := TmpStr + #10 + ZStoredProc.FieldByName('NOM').asString; ZStoredProc.Next; end; ShowMessage(TmpStr); end;

---

Comme pour l'affichage, j'ai trouvé sur le net l'expression

Code:

---

ZStoredProc.ParamByName('NOM').asString

---

au lieu de

Code:

---

ZStoredProc.FieldByName('NOM').asString

---

Là, c'est l'erreur fatale.
Je clos enfin le sujet non sans remercier le seul contributeur qui a eu la patience et la persévérance de m'aider pendant plus de 2 semaines.
Je ne vous connais pas SergioMaster, je ne sais rien de vous mais je vous dis du fond du cœur que votre dévouement fait de vous un type bien.
Un vieux programmeur en applications cartographiques (rien à voir avec les bases de données).