FB 2.1 et 2.5 dans Windows 7: UDF volage

[a.fortuny]

Bonjour la liste.

J'ai un sérieux problème de fonctionnement de Firebird 2.1 (et 2.5) dans un Windows 7 (tant pro que ultimate) .
Installation: machine virtuelle dans un host ESX dans un gros serveur
4 gb mémoire, Windows 7 pro 32 bits anglais, rien de bien particulier; 1 admin et 1 user avec droits administrateur.

Installation de Firebird 2.1.3 en mode manuel (fichier zip)
unzip et copie des fichiers dans C:\Program Files\Firebird\Firebird 2.1
création d'un shortcut sur fbguard.exe avec paramètre "-a" dans la ligne de commande pour lancer firebird en mode application.
copie d'une dll Application.dll dans le répertoire udf de firebird avec celles qui y sont déjà.
lancement de fbguard: l'icône apparait dans le tray, tout OK
Lancement de IBExpert
création de connexions.
tests de connexion: OK
PUIS:
création d'une connexion "Compta", sur une DB qui contient dans les triggers des appels à des UDF de Application.dll et ce depuis les triggers système
active on transaction start ( et transaction commit et rollback) !!
dès la connexion: plantage

Résultats:
erreur de Firebird:
invalid request BLR at offset 478.
function DATETIMETOSTR is not defined.
module name or entrypoint could not be found.

erreur confirmée dès le lancement via isql:
Database: c:\Data\DB\compta1.fdb, User: sysdba
Statement failed, SQLSTATE = 39000
invalid request BLR at offset 478
-function DATETIMETOSTR is not defined
-module name or entrypoint could not be found
Statement failed, SQLSTATE = 39000
invalid request BLR at offset 478
-function DATETIMETOSTR is not defined
-module name or entrypoint could not be found

Deux sous-produit inattendus et désolants:
1. le shutdown à travers de l'icone de FBguard ne tue pas le serveur. Il faut y aller manu military via le contrôleur de processus
2. il semble que la connexion n'est pas rompue car les propriétés de Firebird renseignent toujours une connexion active après le plantage

alors:
- le fichier Application.dll est bien dans le répertoire udf de Firebird
- c'est le bon fichier dll avec le bon nom (copié d'un autre poste où elle fonctionne, binaire identique)
- la DB est une DB copiée d'un autre poste où tout fonctionne à merveille
l'ensemble (DB, UDF et Firebird) fonctionne parfaitement sur ma station de travail vista pro et sur des XP
- les moteurs de Firebird sont lancés en mode application (ports différents)
- la même DB et le même fichier dll fonctionnent avec 2.1 et 2.5, même en simultané dans deux sessions.

Au vu des messages soit
- la fonction n'existe pas (DATETIMETOSTR) ce qui est exclu
- la dll n'est pas accessible par Firebird d'une manière que je ne parviens pas à m'expliquer
avec 2.1 ET 2.5 installés manuellement en tous les deux actifs

Si vous avez une solution sous le coude ou quelques idées elles seraient les bienvenues.

Antonio.

[makowski]

dans win7 il faut être super admin pour travailler sur ce qui est dans C:\Program Files
ceci peut expliquer cela

[a.fortuny]

Envoyé par makowski

dans win7 il faut être super admin pour travailler sur ce qui est dans C:\Program Files
ceci peut expliquer cela

Merci Philppe mais nous y avions déjà pensé. Mon message étant déjà long, je n'ai pas listé tout ce que nous avons fait comme variantes possibles et imaginables, y compris les installations standard comme service avec toujours les mêmes résultats.
On a tout déménagé dans C:\Firebird 2.1 avec exactement le même résultat.

Autre précision dans le même sens:
Dans une nouvelle DB où la connexion ne pose pas de problèmes et qui n'utilise pas d' UDF nous avons procédé au test suivant:

Code :

1
2
3
4
5
SET sql dialect 3;
DECLARE EXTERNAL FUNCTION DATETIMETOSTR
TIMESTAMP
RETURNS CSTRING(254) CHARACTER SET NONE
ENTRY_POINT 'DateTimeToStr' MODULE_NAME 'Application.dll';

et ensuite:

Code :

SELECT datetimetostr('now') FROM synchrodb;

le résultat est désespérément identique

Par contre le query suivant s'exécute bien:

Code :

SELECT abs(-123.456) FROM synchrodb

où abs semble être une UDF décrite dans ib_udf.dll venant avec Firebird.

Antonio.

[Barbibulle]

Envoyé par a.fortuny

Autre précision dans le même sens:
Dans une nouvelle DB où la connexion ne pose pas de problèmes et qui n'utilise pas d' UDF nous avons procédé au test suivant:

set sql dialect 3;
DECLARE EXTERNAL FUNCTION DATETIMETOSTR
TIMESTAMP
RETURNS CSTRING(254) CHARACTER SET NONE
ENTRY_POINT 'DateTimeToStr' MODULE_NAME 'Application.dll';

et ensuite:
select datetimetostr('now') from synchrodb;

le résultat est désespérément identique

Bonjour,

En avez vous profité pour tester une autre fonction de Application.dll (j'imagine que vous en avez d'autres dedans.) Notamment s'il y a des fonctions sans string.
Juste pour voir si c'est la fonction ou si c'est vraiment la DLL

Qu'y a t'il dans le firebird.conf notamment pour "UdfAccess =" ?

Dernière chose, ABS est maintenant une fonction intégrée depuis la version... 2.x. Donc votre test select abs(-123.12) from... ne prouve pas que firebird arrive à charger les UDF.

[a.fortuny]

Envoyé par Barbibulle

En avez vous profité pour tester une autre fonction de Application.dll (j'imagine que vous en avez d'autres dedans.) Notamment s'il y a des fonctions sans string.
Juste pour voir si c'est la fonction ou si c'est vraiment la DLL

En effet, c'était bien le test avec l'UDF DateTimeToStr qui n'existe que dans Application.dll. A chaque nouvel essai je le repasse sans succès.

Envoyé par Barbibulle

Qu'y a t'il dans le firebird.conf notamment pour "UdfAccess =" ?

très simple:
#
#UdfAccess = Restrict UDF

Envoyé par Barbibulle

Dernière chose, ABS est maintenant une fonction intégrée depuis la version... 2.x. Donc votre test select abs(-123.12) from... ne prouve pas que firebird arrive à charger les UDF.

En effet c'est la réflexion que je me suis faite

Merci en tout cas de répondre

Antonio.

[Barbibulle]

Envoyé par a.fortuny

En effet, c'était bien le test avec l'UDF DateTimeToStr qui n'existe que dans Application.dll. A chaque nouvel essai je le repasse sans succès.

Non je me suis mal fait comprendre, avez vous essayé une autre fonction de votre DLL ?

Ou même une fonction fournie dans les UDF de firebird comme

Code :

1
2
3
4
declare external FUNCTION addYear
timestamp, int
returns timestamp
entry_point 'addYear' module_name 'fbudf';

Code :

SELECT addYear('now',1) FROM rdb$database;

[a.fortuny]

Bien vu.

Même erreur avec

Code :

"SELECT addYear('now',1) FROM rdb$database;"

An error was found in the application program input parameters for the SQL statement.
Dynamic SQL Error.
SQL error code = -804.
Function unknown.
ADDYEAR.

Ensuite exécution du query fbudf.sql qui se trouve dans le répertoire UDF de Firebird 2.1
re-soumission de la requête et tout fonctionne.

Re-test avec trois autres fonctions de Application.dll et toujours la même erreur.
les déclarations que j'ai ajoutées (extrait):

Code :

1
2
3
4
DECLARE EXTERNAL FUNCTION CODE_SEMAINE
TIMESTAMP
RETURNS INTEGER BY VALUE
ENTRY_POINT 'CodeSemaine' MODULE_NAME 'Application.dll';

Code :

query: SELECT code_semaine('now') FROM synchrodb

Invalid token.
invalid request BLR at offset 60.
function CODE_SEMAINE is not defined.
module name or entrypoint could not be found.

J'ai tout vérifié sur ma station VIsta jusqu'à faire un fc des deux dll qui ne donne aucune différence: fichiers identiques.

A en perdre le peu de latin qui me reste et je sens que ça va être une toute petite c....ie comme ça

Merci de vous occuper de mon cas. Désespéré ? De Windoze, oui.

Antonio.

[Barbibulle]

Essayez de changer de firebird.conf

UdfAccess = Restrict c:\UDF

Créez le répertoire UDF à la racine de C et placez y application.dll

Arretez FB et relancez le.

Normalement le

Code :

SELECT addYear('now',1) FROM rdb$database;

ne doit plus fonctionner puisque vous n'avez pas copié fbudf.dll dans c:\UDF
(permet de vérifier que le .conf à bien été pris en compte)

Enfin testez votre fonction :

Code :

SELECT CODE_SEMAINE ('now') FROM rdb$database;

[makowski]

Envoyé par a.fortuny

Installation de Firebird 2.1.3 en mode manuel (fichier zip)

les runtimes MSVC ont été installé sur cette machine ?

[a.fortuny]

Dans tout ce qui suit, Firebird a été (re-)installé via l'exe comme service sous un utilisateur ayant les droits d'administrateur (celui demandé lors de l'installation de W7).
FB a été testé pour l'exécution et fonctionne bien quand il n'y a pas d'accès aux fonctions UDF dans une dll externe.
Le service a été ensuite désactivé et un shortcut a été crée sur fbguard.exe avec le paramètre -a pour un lancement comme application, lequel shortcut a été ensuite configuré pour être lancé comme administrateur. Les options de compatibilité ne sont pas activées, donc W7 32bits natif.

Envoyé par Barbibulle

Essayez de changer de firebird.conf
UdfAccess = Restrict c:\UDF
Créez le répertoire UDF à la racine de C et placez y application.dll
Arretez FB et relancez le.

OK tout fait
NB: l'ancien répertoire Firebird\UDF laissé tel quel mais sans Application.dll

Envoyé par Barbibulle

Normalement le

Code :

SELECT addYear('now',1) FROM rdb$database;

ne doit plus fonctionner puisque vous n'avez pas copié fbudf.dll dans c:\UDF
(permet de vérifier que le .conf à bien été pris en compte)

Que nenni: jusque là, ce query fonctionne toujours.
Par contre si je vide Firebird\UDF alors là, oui, le query ne fonctionne plus avec l'habituel message
invalid request BLR at offset 63.
function addYear is not defined.
module name or entrypoint could not be found.

Envoyé par Barbibulle

Enfin testez votre fonction :

Code :

SELECT CODE_SEMAINE ('now') FROM rdb$database;

Qui ne veut toujours pas fonctionner

Dernier test dérivé du vôtre:
- stop du serveur
- création de Firebird\UDF2
- déplacement des DLL de .\UDF --> .\UDF2, donc .\UDF est vide

dans Firebird.conf: UdfAccess = Restrict UDF2

relancer le serveur

Code :

SELECT addYear('now',1) FROM rdb$database;

donne l'erreur déjà bien connue

variante finale:
- stop du serveur
- on laisse tout tel quel
- copie des DLL de .\UDF2 --> .\UDF
- relancer le serveur

Code :

SELECT addYear('now',1) FROM rdb$database;

qui cette fois-ci fonctionne bien

dans toutes les variantes tous les queries faisant appel à une fonction de Appplication.dll ne sont pas connues.

Ces tests indiquent que:
1. le répertoire iniital .\UDF est hardcodé et constitue le défaut dans Firebird ce qu'indique le commentaire de UdfAccess
2. soit la définition de UdfAccess ne fonctionne pas quoique l'on y mette soit le ou les répertoires ne sont pas accessibles de Firebird pour une raison que j'ignore encore.
3. quel que soit le fichier dll ajouté au répertoire par défaut il semble ne pas être accessible
http://www.developpez.net/forums/ima...es/sacrain.gif

Antonio.

[a.fortuny]

Envoyé par makowski

les runtimes MSVC ont été installé sur cette machine ?

En fait lors des premiers test avec 2.5, j'ai vu un répertoire Win32 qui contenait un .msi: à toutes fins utiles, je l'avais installé et n'a pas été desinstallé depuis lors.

Par précaution encore j'ai téléchargé et exécuté vcredist_x86.exe. Cela n'a rien changé aux résultats. Touts les tests de mon post précédent ont été réalisés après cette installation.

Antonio.

[Barbibulle]

Envoyé par a.fortuny

Ces tests indiquent que:
1. le répertoire iniital .\UDF est hardcodé et constitue le défaut dans Firebird ce qu'indique le commentaire de UdfAccess
2. soit la définition de UdfAccess ne fonctionne pas quoique l'on y mette soit le ou les répertoires ne sont pas accessibles de Firebird pour une raison que j'ignore encore.
3. quel que soit le fichier dll ajouté au répertoire par défaut il semble ne pas être accessible
http://www.developpez.net/forums/ima...es/sacrain.gif

Antonio.

Avez vous bien enlevé le # en début de ligne devant le UdfAccess = ?

[a.fortuny]

Envoyé par Barbibulle

Avez vous bien enlevé le # en début de ligne devant le UdfAccess = ?

Oui.

[Barbibulle]

A croire que ce n'est pas le bon firebird.conf ou bien qu'il n'arrive pas à le lire (vous fermez l'éditeur de firebird.conf avant de tester ?).

Sinon avez vous essayé de renommer votre application.dll en app.dll (nom de moins de 8 lettres).

Et de vérifier le nom dans une fenetre "cmd". (histoire d'être certain que ce n'est pas un app.dll.dll). (oubien de renommer avec un .bat comme celui en dessous)

Code renomer.bat :

1
2
move application.dll app.dll
pause

Puis de refaire la déclaration

Code :

1
2
3
4
DECLARE EXTERNAL FUNCTION CODE_SEMAINE
TIMESTAMP
RETURNS INTEGER BY VALUE
ENTRY_POINT 'CodeSemaine' MODULE_NAME 'app.dll';

Et de re-tester

Code :

SELECT CODE_SEMAINE ('now') FROM rdb$database;

[a.fortuny]

Envoyé par Barbibulle

A croire que ce n'est pas le bon firebird.conf ou bien qu'il n'arrive pas à le lire (vous fermez l'éditeur de firebird.conf avant de tester ?).

Oui

Envoyé par Barbibulle

Sinon avez vous essayé de renommer votre application.dll en app.dll (nom de moins de 8 lettres).

oui

Envoyé par Barbibulle

Et de vérifier le nom dans une fenetre "cmd". (histoire d'être certain que ce n'est pas un app.dll.dll). (oubien de renommer avec un .bat comme celui en dessous)

oui et en

Code :

runas /user:administrator cmd

Envoyé par Barbibulle

Code renomer.bat :

Exécuté en ligne de commande

Envoyé par Barbibulle

Puis de refaire la déclaration

Code :

Et de re-tester

Code :

SELECT CODE_SEMAINE ('now') FROM rdb$database;

même réponse, y compris si "[...]ENTRY_POINT 'CodeSemaine' MODULE_NAME 'app'

Antonio.

[makowski]

c'est la dll qui doit avoir un probleme du genre une dépendance manquante

de toutes façons, franchement les UDF, il est préférable de s'en passer
mais c'est une autre débat

[man333]

Après m'être cassé la tête sur le même problème, je l'ai résolu de la manière suivante : copier la gds32.dll dans le répertoire Windows. Apparamment cette dll est nécessaire. Merci de me dire si celà fonctionne pour vous.
David

[makowski]

oui c'est forcément une dépendance manquante pour l'udf
comment est construite cette udf ?

cela peut être une dépendance aussi à ib_util.dll
essayez en mettant le répertoire bin de firebird dans le path

ceci dit, franchement il faut au maximum eviter les udf, ne serait ce que pour être plus portable

la règle avec les udf surtout maison c'est de d'abord tout faire pour ne pas en utiliser, cela évite bien des ennuis et est plus performant et dans 90% au moins des cas d'utilisation d'udf que je vois, on peut très bien s'en passer