At 11:09 PM 2/09/2003 +0000, you wrote:

>a FB SS 1.03 database was uncorrectly uploaded to a Linux remote
>server where a given UDF (say function X) had no proper definition in
>a .so file.
>
>I tried to modify the only procedure that used X (say procedure P),
>but the "alter procedure" command returned the error message
>
>unsuccessful metadata update
>-ERASE RDB$PROCEDURE_PARAMETERS failed
>-invalid request BLR at offset 52
>-function X is not defined
>-module name or entrypoint could not be found
>
>I had to download the whole database to a Windows server where
>function X was defined, modify procedure P, then upload the server
>again.
>
>This had to be done during the night, when fortunately no user was
>attached to the Linux server.
>
>This was the only way I could fix the problem.
>
>I wonder why FB needs to stick its nose into the involved UDFs when
>the "alter procedure" command is issued...
>
>Did I miss a much easier safety path ?

This is a **relational** database. That means it has DEPENDENCIES. The
SQL language - specifically, here, the DDL subset - has a lot of stuff
going on at the binary language level to protect dependencies - that's how
a RDBMS works.

A UDF declaration is a database object. When you (validly) declare a UDF
to a database, it becomes a database object, with a dependency between the
UDF object in the database and the library and entry point in the local
system. As soon as a SP or constraint uses a UDF, a dependency is created
between this UDF object and the SP or constraint. So, by the chain of
dependencies, you make the SP or constraint dependent on the presence of
the external dynamically-linked object supplying the valid entry
point. That's why FB has to stick its nose into UDFs when you refer to the
object.

Of course, because different platforms use completely different external
objects, use of UDFs - especially custom ones - reduces the cross-platform
portability of your database. It's a good argument for never using custom
UDFs unless there are versions of them available for all of the platforms
you'll want to use the database on.

There is no "easier path" than removing the local dependencies *before* you
port the database. You'll have similar challenges with other external
artifacts - blob filters, external tables, language plug-ins.

However....
in this particular case, it is possible that the database was using UDFs
from one of the standard UDF libraries, and that the function couldn't be
found because of one or more of the following causes:

1. The UDF was declared on the Windows database using the ".dll" extension
in the MODULE_NAME parameter. UDFs that are supported on both Windows and
Linux won't be portable if you do this. The CORRECT syntax for MODULE_NAME
is, e.g. 'ib_udf', not 'ib_udf.dll' or 'ib_udf.so'.

2. MODULE_NAME is also **case-sensitive** on Linux, but not on
Windows. Careless declarations on Windows can cause porting problems.

3. On the Linux system, the location of the UDF library may be
misconfigured, or not configured at all.

4. There symlink between the actual UDF library in your Linux installation
and the symbolic name that the server looks for might be invalid (wrong
case, location, etc.)

heLen