| Subject | Re: [firebird-support] FreeAdhocUDF and Firebird 3 not working |
|---|---|
| Author | Helen Borrie |
| Post date | 2017-09-08T23:42:36Z |
Friday, September 8, 2017, 9:08:00 PM, kerry@... wrote:
symptoms. He was trying to use the Tracker to fix the symptoms. It is
an old report and core devs were involved, meaning they investigated
it and couldn't reproduce it.
to new BLR). You have an error somewhere that 2.5 ignored, while 3.0
reacts to something in the legacy BLR that is not valid. With that
error, a likely cause is wrong definition of the module name, i.e., it
was defined with the full name of the DLL instead of the 'name' portion
alone. That is not "newly wrong" - it always was - but it was not
necessarily enforced in the past. My guess is that someone caught
this in some core code cleanup during implementation of stored
functions in Fb3 and you had historically faulty declarations that
became victim to an inherited hack.
Check that:
select * from rdb$functions
If you see anything except the name part of the DLL module, you have
found the problem. Fixing it won't be so simple, as you cannot edit
the system tables in Fb 3. You will have to find and eliminate any
dependencies, drop the offending functions and re-declare them.
If you have a trigger or a procedure that invokes the function, as a
reality check, you could apply a CREATE OR ALTER operation to it,
using the extracted source text. If it refuses to compile, note the
error that is thrown. Chances are, it will get you closer to the
source of your problem.
Make sure you give EXECUTE privs on the function to the trigger or
procedure first.
you were, you would not even consider using UDFs.
Helen
> Thank you for your reply. I mentioned that this problem wasFrom that discussion, Mr da Costa and you are encountering the same
> reported in the Tracker system (Bug CORE-5306) and my problem is just the same.
symptoms. He was trying to use the Tracker to fix the symptoms. It is
an old report and core devs were involved, meaning they investigated
it and couldn't reproduce it.
> Basically I get the following type of errorWhen you upgrade a database, objects are not recompiled (reconverted
> invalid request BLR at offset 36.
> function EXTRACTDAY is not defined.
> module name or entrypoint could not be found.
to new BLR). You have an error somewhere that 2.5 ignored, while 3.0
reacts to something in the legacy BLR that is not valid. With that
error, a likely cause is wrong definition of the module name, i.e., it
was defined with the full name of the DLL instead of the 'name' portion
alone. That is not "newly wrong" - it always was - but it was not
necessarily enforced in the past. My guess is that someone caught
this in some core code cleanup during implementation of stored
functions in Fb3 and you had historically faulty declarations that
became victim to an inherited hack.
Check that:
select * from rdb$functions
If you see anything except the name part of the DLL module, you have
found the problem. Fixing it won't be so simple, as you cannot edit
the system tables in Fb 3. You will have to find and eliminate any
dependencies, drop the offending functions and re-declare them.
If you have a trigger or a procedure that invokes the function, as a
reality check, you could apply a CREATE OR ALTER operation to it,
using the extracted source text. If it refuses to compile, note the
error that is thrown. Chances are, it will get you closer to the
source of your problem.
Make sure you give EXECUTE privs on the function to the trigger or
procedure first.
> I only have one user on all of my installs and that is SYSDBA.So apparently you're not bothered by vulnerabilities. Actually, if
you were, you would not even consider using UDFs.
Helen