Subject Re: stuck
Author Peppe Polpo
--- In, Helen Borrie <helebor@t...>

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

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
> >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
> >-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
> SQL language - specifically, here, the DDL subset - has a lot of
> 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
> 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
> system. As soon as a SP or constraint uses a UDF, a dependency is
> between this UDF object and the SP or constraint. So, by the chain
> 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
> objects, use of UDFs - especially custom ones - reduces the cross-
> portability of your database. It's a good argument for never using
> UDFs unless there are versions of them available for all of the
> 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
> artifacts - blob filters, external tables, language plug-ins.
> However....
> in this particular case, it is possible that the database was using
> 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"
> 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
> is, e.g. 'ib_udf', not 'ib_udf.dll' or ''.
> 2. MODULE_NAME is also **case-sensitive** on Linux, but not on
> Windows. Careless declarations on Windows can cause porting
> 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
> and the symbolic name that the server looks for might be invalid
> case, location, etc.)
> heLen