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

Citation:

---

Envoyé par defluc

Comme je m'y attendais, avec la sous-chaîne «arylè», la procedure FIELD_FROM_SUBSTR ne renvoit rien.

---

et c'est plus ou moins normal puisque cela va dépendre de facteur tel l'encodage de la base de données (CHARSET)

par exemple avec le charset NONE pour le è devrait être transformer au débotté : en ASCII_CHAR(0xE8)

testez ce SQL sur une base CHARSET NONE

Code:

---

1 2 3

select 1,'marylène',UPPER('marylène') ,LOWER('marylène') from rdb$database UNION select 2,'MARILÈNE',UPPER('MARILÈNE') ,LOWER('MARILÈNE') from rdb$database

---

vous obtenez

Citation:

---

1 marylène MARYLèNE marylène
2 MARILÈNE MARILÈNE marilÈne

---

normal car :

Citation:

---

Envoyé par doc Firebird

CHARSET NONE, no character set applied. With this character set setting, Firebird is unable to perform conversion operations like UPPER() correctly on anything other than the standard 26 latin letters.

---

autre référence https://firebirdsql.org/en/firebird-...ts-collations/ (note 97 to 122 correspond à a-z), je pense que ce qui est valable pour UPPER l'est aussi pour LOWER

mais sur une base UTF8, on obtient quelque chose de correct !

Citation:

---

1 marylène MARYLÈNE marylène
2 MARILÈNE MARILÈNE marilène

---

Je reporte à plus tard la question des caractères accentués parce que ma base de données est bien définie en UTF8 dans IBExpert où la case Do NOT perform conversion from/to UTF8 n'est pas cochée. La police : jeu de caractère est ANSI_CHARSET. LIKE reste cependant inopérant.

Ma préoccupation urgente restant mon application Delphi, j'ai testé dans ce contexte l'instruction opérationnelle dans IBExpert :

Code:

---

Select NOM FROM field_from_substr('"TableProprio"', 'NOM', 'Maryl')

---

En voici le code

Code:

---

1 2 3 4 5 6

TmpStr := 'SELECT NOM FROM field_from_substr(' + QuotedStr('"TableProprio"') + ', ' + QuotedStr('NOM') + ', ' + QuotedStr('Maryl') + ')'; CadaDataModule.ZQuery.SQL.Clear; CadaDataModule.ZQuery.SQL.Text := TmpStr; MessageBox(0,PChar(TmpStr),'CadaCom',MB_ICONINFORMATION); CadaDataModule.ZQuery.ExecSQL;

---

Ce code engendre l'erreur

Citation:

---

Le projet MonProjet.exe a provoqué une classe d'exception EZSQLException avec le message : 'Error SQL: invalid request BLR at offset @1 BLR syntax error: expected @1 at offset @2, encountered @3. Error Code: -104. Invalid token The SQL: Select NOM FROM field_from_substr('"TableProprio"', 'NOM', 'Maryl')
;'. Processus stoppé.

---

Je ne suis pas encore au bout de mes peines.

Bonjour,

Citation:

---

Envoyé par defluc

La police : jeu de caractère est ANSI_CHARSET.

---

La police de ? tu parles de l'affichage IBExpert ou de la COLLATION

Citation:

---

ma base de données est bien définie en UTF8 dans IBExpert

---

étrange car si j'en crois ce tableau UTF8 n'existe pas comme nom de CHARSET
IBExpert embrouille peut être les choses ... le mieux serait d'aller voir directement dans la BDD

Code:

---

1 2 3 4 5 6 7 8 9

SELECT a.RDB$FIELD_NAME, a.RDB$RELATION_NAME, b.RDB$CHARACTER_SET_ID, c.RDB$CHARACTER_SET_NAME,b.RDB$COLLATION_ID FROM RDB$RELATION_FIELDS a INNER JOIN RDB$FIELDS b ON b.RDB$FIELD_NAME = a.RDB$FIELD_SOURCE INNER JOIN RDB$CHARACTER_SETS c ON c.RDB$CHARACTER_SET_ID = b.RDB$CHARACTER_SET_ID WHERE RDB$RELATION_NAME = 'TableProprio'

---

devrait permettre de lever le doute.

Code:

---

1 2	TmpStr := 'SELECT NOM FROM field_from_substr(' + QuotedStr('"TableProprio"') + ', ' + QuotedStr('NOM') + ', ' + QuotedStr('Maryl') + ')';

---

Citation:

---

Ce code engendre l'erreur

---

normal, (IBExpert te met dans les choux avec ses guillemets inutiles) , à mon avis tmpstr contient un peu trop de ''''
je propose cette approche

Code:

---

1 2 3 4

TmpStr := Format ('SELECT NOM FROM field_from_substr (%s ,%s, %s)', [QuotedStr('TableProprio'), Quotedstr('NOM'), Quotedstr('Maryl')])

---

Le fait d'être sur une vieille version de ZEOSLIB (6.6.6 ?) , avec une version Delphi que je n'ai pas, n'aide pas non plus, impossible de tester vraiment

Voici l'image IBExpert d'info de connexion de la BD.Pièce jointe 368829et celle résultant de la requête

Code:

---

1 2 3 4 5 6 7 8

SELECT a.RDB$FIELD_NAME, a.RDB$RELATION_NAME, b.RDB$CHARACTER_SET_ID, c.RDB$CHARACTER_SET_NAME,b.RDB$COLLATION_ID FROM RDB$RELATION_FIELDS a INNER JOIN RDB$FIELDS b ON b.RDB$FIELD_NAME = a.RDB$FIELD_SOURCE INNER JOIN RDB$CHARACTER_SETS c ON c.RDB$CHARACTER_SET_ID = b.RDB$CHARACTER_SET_ID WHERE RDB$RELATION_NAME = 'TableProprio'

---

Pièce jointe 368832
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.
J'ai également réessayé Flamerobin qui est nettement moins convivial que IBExpert mais je n'ai pas trouvé comment effectuer certaines modifications et à la fermeture je me retrouve avec le message me disant que les modifications seront perdues si Commit n'est pas exécuté. Mais pas moyen de trouver comment ce faire.
Last but not least, l'instruction

Code:

---

1 2 3 4

TmpStr := Format ('SELECT NOM FROM field_from_substr (%s ,%s, %s)', [QuotedStr('TableProprio'), Quotedstr('NOM'), Quotedstr('Maryl')]);

---

génère exactement la même erreur sous Delphi.
J'ai essayé plusieurs solutions concernant l'erreur "invalid request BLR", dont celle de SergioMaster, proposées sur la toile mais sans succès.

Bon,
puisque ce SQL ne fonctionne pas alors employons les grands moyens

Code:

---

1 2 3 4 5 6

CadaDataModule.ZQuery.Active:=False; CadaDataModule.ZQuery.SQL.Text := 'SELECT NOM FROM field_from_substr (:T,:C,:S)'; CadaDataModule.ZQuery.ParamByName('T').asSTring:='TableProprio'; CadaDataModule.ZQuery.ParamByName('C').asSTring:='NOM'; CadaDataModule.ZQuery.ParamByName('S').asString:='Maryl'; CadaDataModule.ZQuery.Active:=True;

---

Citation:

---

J'ai également réessayé Flamerobin qui est nettement moins convivial que IBExpert mais je n'ai pas trouvé comment effectuer certaines modifications et à la fermeture je me retrouve avec le message me disant que les modifications seront perdues

---

un petit bouton [V] permet de valider (commit) , un second [X] (rollback) de ne pas valider la transaction en cours, moins convivial mais moins "lourd" et tournant aussi sous Linux

En tout cas
- l'image du résultat de la requête est explicite, la colonne étant en charset NONE explique que le problème des caractères comme le è de Marylène, il y a également de forte chance que votre base ait été crée en WIN1252 par défaut (ce qui expliquerait le charset des autres colonnes)

- l'image des infos clients de IBExpert elle me fait remarquer plusieurs choses :

1. Il y a de fortes chances que la connexion ne se fasse pas par la même blibliothèque dll que la connexion ZEOSDBO (normalement <installation Firebird>\bin\fbclient.dll)
2. Vous vous connectez à la base de données via IBEXpert selon le mode page UTF8 et vous affichez en ANSI_CHARSET

Citation:

---

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.

---

Comme indiqué, FB 1.5 ne connaissait pas UTF8 mais UNICODE_CSS (à abandonner)
Changer de CHARSET une colonne ne se fait pas de manière simple, loin de là à mon avis il faut passer par une moulinette programme (à moins que IBExpert pro le fasse ?)
en tout cas un SQL genre UPDATE TABLE SET NOMENUTF8=NOM risque fort de renvoyer une erreur "malformed string"

Le reste de la table étant en WIN1252 plus étendu que ISO8859_1 c'est une question ensuite choix de COLLATION qui va jouer
WIN1252 -> PXW_INTL850
ISO8859_1 -> FR_FR
Là encore le fait d'avoir une base FB 1.5 est pénalisant puisque l'UTF8 n'est inclus qu'à partir de FB 2.0
la COLLATION de UTF8 s'améliore ensuite par rapport à la version 2.0
UNICODE_CI Case insensitive collation (Firebird 2.1)
UNICODE_CI_AI Case insentive, Accent insensitive collation (Firebird 2.5)
Dans le cas de la colonne NOM le mieux eut été CHARSET UTF8 COLLATION UNICODE_CI_AI ainsi, plus besoin du LOWER et la gestion des problèmes d'accent réglé dans le sens où Marylène=marylene=MARYLÈNE=maryléne etc...

J'ai fait un test rapide avec D7 et ZEOSDBO 7.1.3

j'ai complètement oublié que l'on avait affaire à une procédure :arf:
la solution consiste donc peut être à passer non par un Zquery mais un ZStoredProc

Code:

---

1 2 3 4 5 6 7 8 9 10 11

procedure TForm1.Button1Click(Sender: TObject); begin with ZStoredProc1 do begin ParamByName('TABLENAME').asString:='TEST'; ParamByName('COLNAME').asString:='NOM'; ParamByName('PARTIENOM').asString:='lè'; Open; end; end;

---

ceci fonctionne avec l'environnement indiqué

à noter que un TZReadonlyQuery avec ce SQL 'SELECT * FROM TEST WHERE LOWER(NOM) LIKE LOWER('%Lè%')' fonctionne sans erreur :calim2:
quelque chose comme ceci

Code:

---

1 2 3 4 5 6 7

with ZReadOnlyQuery1 do begin Close; SQL.Text:='SELECT * FROM TEST WHERE LOWER(NOM) LIKE :A'; ParamByName('A').asString:='%lè%'; Open; end;

---

fonctionne aussi
Par contre un LowerCase('LÈ') ne fonctionne pas sous D7 (donne lÈ)

Des heures de test avec recherche sur le web sans pouvoir lever les erreurs qui me font revenir.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

procedure TMainForm.TestClick(Sender: TObject); begin with ZStoredProc do begin StoredProcName := 'FIELD_FROM_SUBSTR'; ParamByName('TableName').asString:='TableProprio'; ParamByName('FieldName').asString:='NOM'; ParamByName('StrSubstr').asString:='rylè'; Open; end; end;

---

Citation:

---

Le projet MonProjet.exe a provoqué une classe d'exception EZSQLException avec le message 'SQL Error: invalid request BLR at Offset @1 BLR syntax error: expected @1 at offset @2, encountered @3. Error Code -104. Invalid token The SQL:SELECT * FROM field_from_substr(?,?,?);'.Processus stoppé.

---

Idem avec le code suivant qui me semblait plus approprié.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

procedure TMainForm.TestClick(Sender: TObject); begin with ZStoredProc do begin StoredProcName := 'FIELD_FROM_SUBSTR'; ParamByName('TableName').Value := '"TableProprio"'; ParamByName('FieldName').Value := 'NOM'; ParamByName('StrSubstr').Value := 'rylè'; Open; end; end;

---

Et j'ai essayé avec toutes les combinaisons guillemets simples, doubles, QuotedStr, ....

Bonjour,

là, je donne ma langue au chat car mes tests, avec un environnement différent il est vrai, fonctionnent !
il n'y aurait-il un autre problème comme un problème de BDD ? Après tout, le BLR c'est le binaire de quelque chose dans la BDD.

Ce qui me fait penser : COLNAME est utilisé deux fois en paramètre, j'ai déjà rencontré il y a fort longtemps un problème de ce genre où il fallait, qu'il n'y ait pas 2 fois le même paramètre, était-ce avec ZEOSDBO je n'en sais plus rien, c'est vieux !

Quid en modifiant la procédure ainsi ?

Code:

---

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

SET TERM ^ ; CREATE PROCEDURE RECHERCHE_P ( TABLENAME CHAR(30), RETCOL CHAR(30), COLNAME CHAR(30), PARTIENOM VARCHAR(30) ) RETURNS ( NOM VARCHAR(30) ) AS DECLARE VARIABLE S VARCHAR(30); DECLARE VARIABLE STMT VARCHAR(1024); BEGIN S=LOWER(:PARTIENOM); STMT='SELECT '||RETCOL||' FROM '||TABLENAME||' where LOWER('||COLNAME||') LIKE (''%'||S||'%'')'; FOR EXECUTE STATEMENT STMT INTO :NOM DO SUSPEND; END^ SET TERM ; ^

---

Je commence à m’emmêler les pinceaux vu les différences dans certaines instructions.

Code:

---

STMT='SELECT '||:"FieldName"||' FROM '||:"TableName"||' WHERE LOWER('||:"FieldName"||') LIKE (''%'||LOWER(S)||'%'')';

---

et

Code:

---

STMT='SELECT '||:"FieldName"||' FROM '||"TableName"||' WHERE LOWER('||"FieldName"||') LIKE (''%'||LOWER(S)||'%'')';

---

D'autre part, IBExpert m'a à nouveau lâché et plutôt qu'à le réinstaller, je suis passé à Flamerobin.
Et miracle, si on peut dire dans la mesure où cela permettra peut-être de faire avancer définitivement le schmilblik, ce qui fonctionnait avec IBExpert (transmis dans mon post du 09/04/2018, 15h45) bute sur des erreurs.

Code:

---

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

---

me génère une erreur similaire à Delphi.

Citation:

---

SQL Message : -104
Invalid token

Engine Code : 335544343
Engine Message :
invalid request BLR at offset 184
BLR syntax error: expected invalid BLR code at offset 184, encountered 181

---

Par acquit de conscience, j'ai testé une requête simple sans problème.

Code:

---

SELECT NOM FROM "TableProprio"

---

Puis j'ai compilé la procédure identique à celle de mon post précité, conséquence, erreur plus fondamentale

Citation:

---

Context: Transaction::Commit

SQL Message : -902
Unsuccessful execution caused by a system error that precludes
successful execution of subsequent statements

Engine Code : 335544831
Engine Message :
Access to UDF library "ib_udf.DLL" is denied by server administrator

---

Un peu plus clair !
apparemment le LOWER appelé fait partie d'une UDF et n'est donc pas le LOWER interne que je connais des versions > 1.5
Il doit donc y avoir, quelque part, dans la base de données, une déclaration d'un fonction UDF à vérifier
en exemple avec flamerobin
Pièce jointe 369444

une déclaration de ce genre

Code:

---

1 2 3 4

DECLARE EXTERNAL FUNCTION LOWER CSTRING(255) RETURNS CSTRING(255) FREE_IT ENTRY_POINT 'IB_UDF_Lower' MODULE NAME 'ib_udf';

---

devrait s'y trouver
N.B. je déclare souvent mes fonctions UDF avec F_xxxx pour les distinguer des fonctions internes

il va falloir aussi vérifier le firebird.conf pour voir ce qu'il en est dans la partie UDF ,
et le répertoire <installation de firebird>\udf qui devrait contenir, à ma souvenance, ib_udf.dll, fbudf.dll

Cette fonction existe bien. Je la vire ?

Bonne question !
déjà il faudrait vérifier cette histoire de

Citation:

---

Access to UDF library "ib_udf.DLL" is denied by server administrator

---

dans le firebird.conf (autorisation) et dans le répertoire UDF (existence)

ensuite je suggère tout d'abord d'essayer avec flamerobin la fonction Select LOWER(nom) FROM TableProprioil peut y avoir là un premier problème

Je ne me souviens plus si il s'agit d'une version 32 bits ou 64 bits (si cela a jamais été indiqué ?) là, s'il y a mélange de genre c'est sûr, ça plante ! mais normalement Firebird 1.5 n'est que 32 bits, au pire sur un Windows 64 Firebird doit être installé en Program Files (x86) et la fbClient.dll dans c:\windows\syswow64 au besoin (surtout pas ailleurs)


redéclarer la fonction et l'utiliser avec le préfixe F_ serait peut être un plus en cas de migration vers un Firebird de version > ;)

Code:

---

1 2 3 4

DECLARE EXTERNAL FUNCTION F_LOWER CSTRING(255) RETURNS CSTRING(255) FREE_IT ENTRY_POINT 'IB_UDF_Lower' MODULE NAME 'ib_udf';

---

Je trouve Ib_udf.DLL dans les dossiers
...FDBConvert pour toutes les versions Firebird (9.216 bytes pour fb20, 11.264 b pour fb21, 25 et 30, 24.756 b pour fb15) et dans
C:\Program Files (x86)\HK-Software\IBExpert\IBEUDB\udf (11.264 b)
et je trouve firebird.conf dans les mêmes dossiers
(18.044 b pour fb15, 27.462 b pour fb30 et 27.468 b) pour fb 25 dans FD...BConvert et
(27.661 b) dans Program Files (x86)\HK-Software\IBExpert\IBEUDB).
Quant à fbclient.dll je le trouve dans.
..FDBConvert\ya (1.519.616 b) et dans
Program Files (x86)\HK-Software\IBExpert\IBEUDB (3.846.144 b).

Après avoir renommé la procédure LOWER en F_LOWER, La requête

Code:

---

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

---

exécutée sous Flamerobin plante avec le message

Citation:

---

Starting transaction...
Preparing query: SELECT NOM FROM field_from_substr('"TableProprio"', 'NOM', 'aryl')
Error: *** IBPP::SQLException ***
Context: Statement: Prepare( SELECT NOM FROM field_from_substr('"TableProprio"', 'NOM', 'aryl') )
Message: isc_dsql_prepare failed

SQL Message : -104
Invalid token

Engine Code : 335544343
Engine Message :
invalid request BLR at offset 184
BLR syntax error: expected invalid BLR code at offset 184, encountered 181

---

Bonjour,

C'est quoi ce répertoire fdbConvert ? En tout cas, ce qui ne me rabiboche pas avec IBExpert c'est que cela fausse tout !
reprenons à la base. Une installation propre de Firebird


Comme IBExpert semble avoir eu des misères sur le poste, le désinstaller proprement (bien tout nettoyer, en particulier au niveau de la base de registre)
Désinstaller aussi FDBConvert !
Installer ensuite FireBird
Normalement, il doit y avoir à la suite un répertoire Firebird dans Program Files (x86) puisque 1.5 est uniquement 32 bits et dans ce répertoire on retrouvera les UDF correctes.
Firebird est installé correctement, de préférence en tant que service, les choses devraient se clarifiées.

Vous pourrez re-installer IBExpert mais après ! quant à fbconvert AMHA c'est totalement inutile, un bon backup de la base avec firebird 1.5, l'installation de FB 2.5 et une restauration du dit backup avec la nouvelle version et le tour est joué. C'est ce que j'ai fait à partir d'une version Interbase 5.4 en passant au fil des versions jusqu'à FB 2.5 et ce avec une base de production)
Seul problème, il n'est pas possible de changer de Dialect, ni de Charset.

la probabilité du problème : La connexion ZEOSDBO rencontrant plusieurs informations de registre lors de la recherche du protocole fait cafouiller le système

Bonjour SergioMaster,

Tout a été désinstallé et nettoyé selon vos directives.
Juste un petit souci pour la réinstallation de Firebird 1.5 résolu grêce à https://www.ibphoenix.com/resources/...eneral/doc_476

Reste à passer aux tests mais auparavant j'ai quelques tâches laissées en suspens depuis 2 semaines qui m'attendent.

En vous remerciant pour votre dévouement,

Bonjour,

Pc redémarré après réinstallation de Firebird mais le serveur ne démarre pas automatiquement.
Je le démarre donc.
La requête de test proposée

Code:

---

1 2 3

select 1,'marylène',UPPER('marylène') ,LOWER('marylène') from rdb$database UNION select 2,'MARILÈNE',UPPER('MARILÈNE') ,LOWER('MARILÈNE') from rdb$database

---

génère l'erreur

Citation:

---

Preparing query: select 1,'marylène',UPPER('marylène') ,LOWER('marylène') from "TableProprio"
UNION
select 2,'MARILÈNE',UPPER('MARILÈNE') ,LOWER('MARILÈNE') from "TableProprio"
Error: *** IBPP::SQLException ***
Context: Statement::Prepare( select 1,'marylène',UPPER('marylène') ,LOWER('marylène') from "TableProprio"
UNION
select 2,'MARILÈNE',UPPER('MARILÈNE') ,LOWER('MARILÈNE') from "TableProprio" )
Message: isc_dsql_prepare failed

SQL Message : -804
An error was found in the application program input parameters for the SQL statement.

Engine Code : 335544569
Engine Message :
Dynamic SQL Error
SQL error code = -804
Function unknown
LOWER

---

Code:

---

select 1,'marylène',upper('marylène') from "TableProprio"

---

fonctionne mais le résultat est surprenant
Pièce jointe 370043
Avec la requête

Code:

---

select 1,'marylène',lower('marylène') from "TableProprio"

---

malgré que lower apparait dans une liste déroulante, c'est «échec»

Citation:

---

Starting transaction...
Preparing query: select 1,'marylène',lower('marylène') from "TableProprio"
Error: *** IBPP::SQLException ***
Context: Statement::Prepare( select 1,'marylène',lower('marylène') from "TableProprio" )
Message: isc_dsql_prepare failed

SQL Message : -804
An error was found in the application program input parameters for the SQL statement.

Engine Code : 335544569
Engine Message :
Dynamic SQL Error
SQL error code = -804
Function unknown
LOWER

---

Quelle galère.

Bonjour,

La fonction LOWER à bien été déclarée ? car en FB 1.5 ce n'est pas une fonction interne, il faut passer par les UDFs

Code:

---

1 2 3 4

DECLARE EXTERNAL FUNCTION LOWER CSTRING(255) RETURNS CSTRING(255) FREE_IT ENTRY_POINT 'IB_UDF_Lower' MODULE NAME 'ib_udf';

---

s'il ne s'agit pas de données sensibles je suis prêt à jeter un oeil sur cette BDD, il suffit de me fournir un backup (en ce cas me MP et je fournirai une adresse mail de réception, ou me fournir un lien de téléchargement via MP)

Vu les erreurs de votre code à la compilation, je l'ai modifié pour répondre aux restrictions trouvées sur le site de Firebird à savoir :
- 1. In Firebird 1.5.1 and below, the default declaration used CSTRING(80) instead of CSTRING(255).
- 2. The NULL after CSTRING(255) is an optional addition that became available in Firebird 2. When declared with the NULL keyword, the engine will pass a NULL argument unchanged to the function. This leads to a NULL result, which is correct. Without the NULL keyword (your only option in pre-2.0 versions), NULL is passed to the function as an empty string and the result is an empty string as well. Et

Code:

---

1 2 3 4

DECLARE EXTERNAL FUNCTION "LOWER" CSTRING(80) RETURNS CSTRING(80) FREE_IT ENTRY_POINT 'IB_UDF_lower' MODULE_NAME 'ib_udf';

---

La fonction LOWER apparait bien sous F_LOWER dans l'arborescence de Flamerobin.
Cependant, rien ne change pour ce qui est des erreurs des requêtes de mon précédent post que ce soit

Code:

---

1 2 3

select 1,'marylène',UPPER('marylène') ,LOWER('marylène') from rdb$database UNION select 2,'MARILÈNE',UPPER('MARILÈNE') ,LOWER('MARILÈNE') from rdb$database

---

ou

Code:

---

select 1,'marylène',lower('marylène') from "TableProprio"

---

.
Mais oh miracle, cela fonctionne après fermeture et réouverture de Flamerobin.
Par contre, la procedure field_from_substr me sort un nouveau message d'erreur

Citation:

---

*** IBPP::SQLException ***
Context:: Statement::Fetch
Message: isc_dsql_fetch failed.

SQL Message : -802
Arithmetic overflow or division by zero has occured.

Engine Code : 335544321
Engine Message:
Arithmetic exception, numeric overflow, or string truncation.

---

J'ai diminué la longueur de la chaine de sortie de la procédure de 180 à 80 mais l'erreur subsiste malgré une compilation sans erreur.Pièce jointe 370117
Selon ce dont je me souviens de mon expérience bien ancienne il est vrai, c'est le champs d'entrée qui n'est pas tronqué et sa longueur dépassant les 180 caractères, a fortiori 80, c'est le plantage.

Bonjour,

Citation:

---

Envoyé par defluc

Vu les erreurs de votre code à la compilation

---

lesquelles ? Je dois avouer, je suis sensible pour ne pas écrire susceptible à ce genre de remarque, si on me dit qu'il y a des erreurs dans mon code j'aime bien en avoir la transcription que vous en avez fait et les erreurs engendrées. Je peux me tromper, c'est vrai mais j'écris ces codes sans contrôle puisque moi je travaille avec des versions plus récentes de Firebird

Citation:

---

1. In Firebird 1.5.1 and below, the default declaration used CSTRING(80) instead of CSTRING(255).

---

à mon avis, une erreur d'interprétation de votre part, il est indiqué la taille par défaut de et non CSTRING est limité à
j'ai ressorti ma vieille documentation d'interbase 5.5 (alors que firebird 1.0 s'appuie sur la version 6.x ) il n'est nulle par mention de cette "limite" à 80 je lit même :

Code:

---

1 2 3 4

// extrait DECLARE EXTERNAL FUNCTION TRIM SMALLINT, CSTRING(256) .....

---

si vous regardez dans le répertoire qui contient les UDF, il doit y avoir un fichier ib_udf.sql qui permet d'avoir toutes les déclarations des fonctions externes
en recherchant, il y a la déclaration de la fonction LOWER (ligne 364 à 367) , le commentaire au dessus indique même que la limite est 32767 ! limite, à l'époque de la taille d'une chaine

Citation:

---

Mais oh miracle, cela fonctionne après fermeture et réouverture de Flamerobin.

---

plutôt après relance du service Firebird (si toutefois il a été installé ainsi)

que viennent faire ces guillemets dans votre code :?:

Code:

---

1 2 3 4

DECLARE EXTERNAL FUNCTION "LOWER" CSTRING(80) RETURNS CSTRING(80) FREE_IT ENTRY_POINT 'IB_UDF_lower' MODULE_NAME 'ib_udf';

---

Citation:

---

Par contre, la procedure field_from_substr me sort un nouveau message d'erreur
J'ai diminué la longueur de la chaine de sortie de la procédure de 180 à 80 mais l'erreur subsiste malgré une compilation sans erreur.

---

AMHA totalement hors cause, mais pour cela il me faudrait le source de cette procédure et la taille de la colonne nom !
en fait il faudrait même que le résultat de sortie de la procédure soit un VARCHAR de taille importante puisque vous paramétrisez à la fois le nom de la table et la colonne (noms de table et noms de colonne sont fixe CHAR(31))
une procédure plus générale devrait donc commencer ainsi

Code:

---

1 2 3 4 5 6 7 8 9

SET TERM ^ ; CREATE PROCEDURE RECHERCHE_P ( TABLENAME CHAR(31), COLNAME CHAR(31), PARTIENOM VARCHAR(xxx) ) RETURNS ( NOM VARCHAR(xxx) ) AS

---

où xxx serait la taille maximum colonne chaine de votre base de données, mais attention, du coup la chaine contenant le STATEMENT (STMT dans le code proposé) se doit d'être plus importante encore ! (environ 130+xxx)

revisité la procédure, utilisant la fonction UDF LOWER (déclaration de IB_UDF.sql donc avec CSTRING(255) ) devrait alors être quelque chose comme

Code:

---

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

SET TERM ^; CREATE PROCEDURE RECHERCHE_P ( TABLENAME CHAR(31), COLNAME CHAR(31), PARTIENOM VARCHAR(255) ) RETURNS ( NOM VARCHAR(255) ) AS DECLARE VARIABLE STMT VARCHAR(1024); // peut être diminuée à 640 BEGIN S=LOWER(:PARTIENOM); STMT='SELECT '||COLNAME||' FROM '||TABLENAME||' where LOWER('||COLNAME||') LIKE %'||S||'%'; FOR EXECUTE STATEMENT STMT INTO :NOM DO SUSPEND; END^ SET TERM ; ^

---

Votre image écran, m'indique que vous persistez à utiliser le nom de table entre guillemets ! pour moi c'est une erreur

Selon ce dont je me souviens de mon expérience bien ancienne il est vrai, c'est le champs d'entrée qui n'est pas tronqué et sa longueur dépassant les 180 caractères, a fortiori 80, c'est le plantage.[/QUOTE]
oui c'est bien une histoire de débordement de taille mais encore faut-il diagnostiquer de qu'elle variable il s'agit, je rappelle que le STATEMENT n'est pas "compilé" dans la procédure mais à l'exécution de celle-ci, c'est le piège de EXECUTE STATEMENT


En guise de POST-SCRIPTUM, une solution sans passer par ces fonctions UDF est possible. Utiliser l'évènement OnFilter de l'ensemble de données et filtrer ce dernier Filitered:=True; permettrait d'utiliser les fonctions de comparaisons de chaines de votre Delphi (j'ose même mentionner les possibilités des expressions régulières, quoique cela demande pour cela d'installer quelques sources)
par exemple :

Code:

---

1 2 3 4

procedure TForm1.ZQuery1FilterRecord(Dataset : TDataset); var Accept : Boolean); begin Accept:=Pos(textearechercher,ZQuery1.FieldByName(colonnearechercher).asString)>=1; end;

---

toutefois, si cela règle le problème des caractères accentués, cela pénalisera la vitesse d'exécution :aie:

Bonsoir SergioMaster,
Désolé de vous avoir vexé ce qui était loin d'être intentionnel. Je suis d'ailleurs un adepte de la communication non violente selon Rosenberg. https://fr.wikipedia.org/wiki/Commun...elon_Rosenberg
Conscient au contraire que le fait de répondre rapidement est très profitable et encourageant pour ceux qui attendent une réponse qui les fera progresser, il me semblait normal qu'une erreur se glisse de temps en temps dans le code. Il m'apparait également qu'il est plus responsable de chercher à lever moi même cette erreur plutôt que de la souligner en attendant servilement une nouvelle réponse.
Je vous présente néanmoins mes excuses pour ce malentendu et pour ce qui est des «erreurs»,
La première provient de la ligne

Code:

---

ENTRY_POINT 'IB_UDF_Lower' MODULE NAME 'ib_udf';

---

Citation:

---

Preparing query: DECLARE EXTERNAL FUNCTION LOWER
CSTRING(255)
RETURNS CSTRING(255) FREE_IT
ENTRY_POINT 'IB_UDF_Lower' MODULE NAME 'ib_udf'
Error: *** IBPP::SQLException ***
Context: Statement::Prepare( DECLARE EXTERNAL FUNCTION LOWER
CSTRING(255)
RETURNS CSTRING(255) FREE_IT
ENTRY_POINT 'IB_UDF_Lower' MODULE NAME 'ib_udf' )
Message: isc_dsql_prepare failed

SQL Message : -104
Invalid token

Engine Code : 335544569
Engine Message :
Dynamic SQL Error
SQL error code = -104
Token unknown - line 4, char 28
MODULE

---

Problème règlé par un espace remplacé par un underscore dans ENTRY_POINT 'IB_UDF_Lower' module_name 'ib_udf';

Pour la deuxième prétendue erreur, autant pour moi ou mea culpa, j'ai effectivement mal interprété le texte relatif à la longueur de la chaine d'entrée et de sortie de la fonction «lower».

J'ai dû reproduire les erreurs pour régénérer leurs messages et j'ai eu quelques difficultés à rendre la fonction LOWER à nouveau opérationnelle.
Alors que la mise entre guillemets et en majuscules s'était imposée à moi à la lecture de la page https://firebirdsql.org/refdocs/lang...udf-lower.html, maintenant cela fonctionne sans guillemets mais uniquement si lower est en minuscule, ce qui correspond d'ailleurs à la définition dans in_udf.sql.

Pour ce qui est de la requête

Code:

---

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

---

, après bien des tatonnements suite à des erreurs de deux types, Colonne unknown 'aryl' et Invalid token '%', elle fonctionne enfin sous la forme

Code:

---

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

SET TERM ^ ; ALTER 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); STMT='SELECT '||FieldName||' FROM '||TableName||' WHERE lower('||FieldName||') LIKE ''%'||S||'%'''; FOR EXECUTE STATEMENT STMT INTO :NOM DO SUSPEND; END^ SET TERM ; ^     GRANT EXECUTE ON PROCEDURE FIELD_FROM_SUBSTR TO SYSDBA;

---

Les deux dernières lignes on été ajoutées par Flamerobin.
Reste un problème de jeu de caractères concrétisé dans l'image jointe.
Pièce jointe 370568
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.
Je le savais mais chaque chose en son temps. Je m'attacherai à régler ce problème plus tard.