Portierung Firebird von Win auf Linux: UDF Lib Fehler

[Delphi.Narium]

Mit welcher Software setzt Du denn das Select f_abs(-1) from rdb$database; ab?

ISQL, FlameRobin, eigene Software?

Gibt es in den neuen Datenbanken die gleichen User mit identischen Passwörtern, wie im "Original"?
Sind irgendwelche Rollen vergeben, stimmen die überein?

Funktioniert der Aufbau einer Verbindung zur Datenbank?

Funktioniert ein Select * from rdb$database; Sprich: Scheitert "nur" der Aufruf der Funktion f_abs(), aber andere Abfragen funktionieren?

Mal die firebird.confs miteinander verglichen?

Hilft die FAQ 203 weiter?

[lowmax_5]

Ggf. ist es möglich, dass unter Linux die UDFLib noch spezielle Rechte des Firebird Dienstes benötigt, damit dieser darauf zugreifen kann. Dieses mal prüfen und schauen unter welchem User der fbserver läuft.
Nach dem Kopieren hat die UDFLib definitiv nicht die benötigen Rechte (Linux )

[IBExpert]

mit fb25 haben wir die freeadhoc udf bei einigen Kunden auch mit linux am laufen, mit fb30
haben wir das nicht mehr ernsthaft weiterprobiert, weil die compilate von der freeadhoc
mit irgendwelchen libs von linux laufen müssen, die aber per default nicht von fb3 benutzt
werden und teilweise kompliziert in neuere Linux versionen eingebaut werden müssen.

Es kann tausend gründe haben, die extrem versions abhängig sind oder ganz banal
fehlende chmod auf relevanten files. Wie schon woanders angedeutet, ich würde mir bei fb3
mit linux aber auch mit windows freeadhoc sowieso nicht mehr freiwillig antun, weil die so
schlecht programmiert ist, das man mit diversen befehlen und unpassenden parametern
den kompletten firebird server dienst für alle user zum absturz bringen kann.

Die alternative die wir dafür bei Kunden nutzen, ist die ibexpert function lib, in der fast
alles drin ist was sinnvoll ist und man braucht dafür auch nix neues im sql anpassen, weil
die gleichen Funktionen (mit ausnahme von zB F_ROSENMONTAG oder ähnlicher unsinn, die sind
zwar drin aber nicht 100% sinnvoll implementiert, ca 95% der Funktionen sind aber komplett und natürlich
erweiterbar, weil wir das produkt als Firebird stored function Quellcode ausliefern) genau
so aufgerufen werden könne, aber mit source als stored function implementiert sind.

Um das in der datenbank umzustellen, würde man mit ibexpert tools-extract metadata mit daten
in seperate files machen und dann vor dem einspielen den teil in der ibe$start.sql , in dem
die bisherigen udfs deklariert sind, durch das neue stored function script ersetzen. Danach
ist eure db auf jeder windows oder linux fb3/fb4/fb5 benutzbar ohne irgendwelche dll/so
basteleien und auch ab fb4 brauchst du nicht die dann eh erst mal per conf deaktivierten
UDFs reaktivieren. Und wenn du das bei dutzenden oder hunderten oder ... Kunden automatisiert
mahen musst, geht auch das mit ibeblock und ibec_extractmetadata in unsere ibescript
script engine auch per batch laufen kann.

Muss aber ja jeder selbst wissen, womit er seine Zeit verbringt ...

[ZOD]

Guten Morgen zusammen!

wir haben das Problem lösen können:

Wir arbeiteten mit symbolischen Links an allen denkbaren
Stellen (das ist die übliche Strategie), aber am Ende mußten wir die
FreeAdhocUDF_FB2x_amd64.so nach FreeAdhocUDF.so explizit KOPIEREN, dann
funktionierte es plötzlich!

Weitere Info: wir verwendeten das Verzeichnis /UDF/ als Speicherort für
die UDF und hatten
UdfAccess=Restrict /UDF in der firebird.conf eingetragen.

Nochmals Dank an alle für die Antworten.

Markus