--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> This is a **relational** database. That means it has

DEPENDENCIES.

Dependencies are our friends.

However when I spend a lot of my valued time (I am getting old :) )
doing things that require my attention instead of my ingenuity, I
feel the tool I am using is not friendly enough.

I much miss a command (like deltree in DOS or rm -r in Unix) that I
can issue to say

"drop procedure Foo cascading"

And it will delete object Foo together with all objects that depend
on it.

Dangerous ?

Not more than rm -r in Unix.

Peppe Polpo

> 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