Doch, UDFs gehen auch noch bis mindestens fb5, aber um die zu nutzen muss man die in der firebird.conf exlizit erlauben.
Es ist aber eindeutig empfohlen, UDFs nicht zu nutzen, weil sehr viele existierende erschreckend schlecht programmiert
sind und bei multithreaded load wegen speicherfehler gerne mal den gesamten prozess per
access violation zum Absturz
bringen.
Das versuchen dann einige zu umgehen, in dem man den classic server nimmt, weil da jede Prozess single threaded
ist und damit die multithread probleme vermieden werden. Das der classic andere erhebliche Nachteile hat wird dann oft
zugunsten der ansonsten nicht mehr gegebenen Stabilität gerne von Softwareherstellern auf den Kunden abgewälzt (langsamer
weil weit mehr I/O Leistung erforderlich).
Wenn man interne Funktionen findet, die den gleichen Zweck erfüllen, ist ein Umstieg darauf mit Abstand der beste Weg. Sollte
die Syntax der Funktion aber anders sein, wie zum beispiel bei substring('ABCD' from 2 for 2) auf eine bisher benutzte UDF
substr('ABCD*,2,2) kann man seit fb3 sigenannte Stored functions erstellen, die syntaxgleich das machen, was man vielleict
im Laufe von Jahrzehnten im eigenen Quellcode an hundersten stellen verteilt hat und da nicht mal eben ändern kann.
UDR sind ähnlich wie UDF, müssen aber anders compiliert sein,weil deren Einbindung auch bei schlechter Implementation
nicht den gesamten Serverprozess zum Absturz bringen. Frei verfügbare UDR Bibliothen sind aber noch rar, aber aufgrund
der sehr vielen internen frei verfügbaren robusten Funktionen längst nicht mehr so oft erforderlich.
Wer also noch seine Software zum Beispiel mit der extrem gruseligen FreeAdHocUDF (oder auch rfunc) Lib verheiratet hat,
dem sei dringend der Umstieg angeraten. Die Freeadhoc hatte ihr letztes Update vor 14 Jahren! Und auf begründete Nachfrage
liefer ich einige simple
SQL Befehle, die mit aufrufen der darin enthaltenen Funktionen mit bestimmten parametern garantiert
jeden Serverrozess abstürzen lässt, der die udf eingebunden hat.
Für diverse Kunden haben wir die Funktionen mal zu stored functions auf Basis derinternen Funktionen portiert und bieten
das auch anderen an
https://ibexpert.net/cms/ibexpertfunctionlibrary
Bei den meisten Projekten, wo wir den Umstieg von
fb<025 auf
fb>=30 per Hotline Support/Workshop unterstützt habe, war oft
eine simple Inventur hilfreich. Nur weil 600 Ufs in der Datenbank deklariert sind, heisst das noch lange nicht das die auch
wirklich alle benutzt werden oder ha jemand von euch schon mal ernsthaft die FreeAdhocUDF Funktionen benutzt, ohne dafür
Standortbezogene Kalender zu implementieren
F_ASCHERMITTWOCH
F_FRONLEICHNAM
F_GRUENDONNERSTAG
F_HIMMELFAHRT
F_KARFREITAG
F_KARNEVALSDIENSTAG
F_OSTERDATUM
F_OSTERMONTAG
F_OSTERSAMSTAG
F_PALMSONNTAG
F_PFINGSTMONTAG
F_PFINGSTSONNTAG
F_ROSENMONTA
F_ROSENMONTAG
F_WEIBERFASTNACHT
Nur weil die im Init Script stehen sollte man die nicht deklarieren und über dependencies bekommt man die wenn die wirklich in der
Datenbank selber in trigger oder stored procs benutzt wurden, finden und hinterfragen.
Oder wieder zurück zum Thema: wis schon angesagt von anderen:
für Stringlänge nimm die interne Funktion char_length (die es auch schon bei fb25 gab)
Ergänzend: Wenn du einen andere Syntax brauchst als die der internen Funktionen, baue dafür stored functions auf basis der internen funktionen.