| Subject | Re: [ib-support] Problem Finding UDF dll |
|---|---|
| Author | Helen Borrie |
| Post date | 2001-11-09T04:00:57Z |
At 04:34 PM 08-11-01 +0200, you wrote:
Your database can access more than one UDF library, as long as the server can find the library named in the MODULE_NAME and ENTRY_POINT named in the function's declaration. Many people in fact use functions from both the udflib.dll (Windows) or udflib.so (Linux/UNIX) and the FreeUDFLib.dll (Windows) or FreeUDFLib.so (Linux/Unix).
Where the problems arise is that, from version to version of InterBase over the years, Borland changes the default location of UDF libraries. Also, in some versions, it is an error to enclose the file suffix (.dll or .so) in the MODULE_NAME entry. It should be omitted, because of the capability of an InterBase/Firebird gbak file to be restored onto a different OS platform. A Linux/Unix server won't find or read a .dll and a Windows server won't find or read a Linux/Unix shared object.
To complicate matters regarding FreeUDFLib (which was written in Pascal): that library was not updated for InterBase 6/Firebird and so none of the date and time functions will work with a Dialect 3 database. Rob Schieck did a Linux port (in C++) of FreeUDFLib last year and, as well as the problems with the date and time functions, there were bugs in some of the other function translations.
With regard to the path where the server looks for the UDF libraries, you can set this up in the ibconfig file by adding one or more entries in the format
EXTERNAL_FUNCTION_DIRECTORY "<path name>"
where <path name> is a physical path on the same machine as the server program and in the format appropriate to the host operating system. Note that the paths must be double-quoted in the ibconfig file. You can include multiple entries if you want the server to search multiple paths for MODULE_NAME.
AFAIK, this configuration option is not available on Classic. However, if your host server is Windows, you can place all your UDFs in the winnt\System32 directory without the need to configure explicitly. I'm afraid I don't know the default directory paths that the server searches on Linux/Unix.
You must also make sure you have a correct declaration for each function in *each* database. Up to the present time, you cannot declare UDFs at server level. And it is probable that the ENTRY_POINT and MODULE_NAME entries in the declarations for IB 6 and Firebird should be in single quotes, not double quotes, which was allowable in previous IB versions.
But, as others have pointed out, if you have a Dialect 3 database, IB 6 and Firebird have inline functions for extracting the elements of dates.
Regards,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________
>HiActually, this is not correct.
>
>I have downloaded FreeUDFLib before 2 months ago.
>I need a date decode function.
>So that i setup the freeudflib.
>But I can't use this function.
>And I seen this message.
>
>
>You must rename of the dll file.
>Because Dll name is wrong.
>I Channged the dll name and everthing is ok.
Your database can access more than one UDF library, as long as the server can find the library named in the MODULE_NAME and ENTRY_POINT named in the function's declaration. Many people in fact use functions from both the udflib.dll (Windows) or udflib.so (Linux/UNIX) and the FreeUDFLib.dll (Windows) or FreeUDFLib.so (Linux/Unix).
Where the problems arise is that, from version to version of InterBase over the years, Borland changes the default location of UDF libraries. Also, in some versions, it is an error to enclose the file suffix (.dll or .so) in the MODULE_NAME entry. It should be omitted, because of the capability of an InterBase/Firebird gbak file to be restored onto a different OS platform. A Linux/Unix server won't find or read a .dll and a Windows server won't find or read a Linux/Unix shared object.
To complicate matters regarding FreeUDFLib (which was written in Pascal): that library was not updated for InterBase 6/Firebird and so none of the date and time functions will work with a Dialect 3 database. Rob Schieck did a Linux port (in C++) of FreeUDFLib last year and, as well as the problems with the date and time functions, there were bugs in some of the other function translations.
With regard to the path where the server looks for the UDF libraries, you can set this up in the ibconfig file by adding one or more entries in the format
EXTERNAL_FUNCTION_DIRECTORY "<path name>"
where <path name> is a physical path on the same machine as the server program and in the format appropriate to the host operating system. Note that the paths must be double-quoted in the ibconfig file. You can include multiple entries if you want the server to search multiple paths for MODULE_NAME.
AFAIK, this configuration option is not available on Classic. However, if your host server is Windows, you can place all your UDFs in the winnt\System32 directory without the need to configure explicitly. I'm afraid I don't know the default directory paths that the server searches on Linux/Unix.
You must also make sure you have a correct declaration for each function in *each* database. Up to the present time, you cannot declare UDFs at server level. And it is probable that the ENTRY_POINT and MODULE_NAME entries in the declarations for IB 6 and Firebird should be in single quotes, not double quotes, which was allowable in previous IB versions.
But, as others have pointed out, if you have a Dialect 3 database, IB 6 and Firebird have inline functions for extracting the elements of dates.
Regards,
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________