SEO

Hi,

I have just successfully restored a database from one Linux box to another.

Unfortunately, on the restored database I get errors stating

SQL0440N No authorised routine named RTRIM of type FUNCTION
having compatible arguments was found SQLSTATE=42884

??

Do I have to restore some UDFs manually or something ?

Thanks.

(Sorry if this is an RTFM, but I'm running out the door to go home
and wanted to catch those on US Time zones :-) )

Paul.

RTRIM is part of the SYSFUN schema in v8. Perpahs you have some sort of
schema issue? You should not have to install a UDF for RTRIM.

Paul Reddin wrote:

> Hi,
>
> I have just successfully restored a database from one Linux box to another.
>
> Unfortunately, on the restored database I get errors stating
>
> SQL0440N No authorised routine named RTRIM of type FUNCTION
> having compatible arguments was found SQLSTATE=42884
>
> ??
>
> Do I have to restore some UDFs manually or something ?
>
> Thanks.
>
> (Sorry if this is an RTFM, but I'm running out the door to go home
> and wanted to catch those on US Time zones :-) )
>
> Paul.

Paul,

Blair is correct, however note that for non-built udfs and stored procs
must be move manually after the restore (known function requirement).

Blair Adamache wrote:

> RTRIM is part of the SYSFUN schema in v8. Perpahs you have some sort of
> schema issue? You should not have to install a UDF for RTRIM.
>
> Paul Reddin wrote:
>
>> Hi,
>> I have just successfully restored a database from one Linux box to
>> another.
>>
>> Unfortunately, on the restored database I get errors stating
>> SQL0440N No authorised routine named RTRIM of type FUNCTION
>> having compatible arguments was found SQLSTATE=42884
>>
>> ??
>>
>> Do I have to restore some UDFs manually or something ?
>> Thanks.
>>
>> (Sorry if this is an RTFM, but I'm running out the door to go home
>> and wanted to catch those on US Time zones :-) )
>>
>> Paul.
>
>

Guys, are you sure? I thought RTRIM was changed into a built in a long
time ago although the sysfun version should still be there.

Paul, do you get the error on a clp query?

Sean McKeough wrote:
> Paul,
>
> Blair is correct, however note that for non-built udfs and stored procs
> must be move manually after the restore (known function requirement).
>
> Blair Adamache wrote:
>
>> RTRIM is part of the SYSFUN schema in v8. Perpahs you have some sort
>> of schema issue? You should not have to install a UDF for RTRIM.
>>
>> Paul Reddin wrote:
>>
>>> Hi,
>>> I have just successfully restored a database from one Linux box to
>>> another.
>>>
>>> Unfortunately, on the restored database I get errors stating
>>> SQL0440N No authorised routine named RTRIM of type FUNCTION
>>> having compatible arguments was found SQLSTATE=42884
>>>
>>> ??
>>>
>>> Do I have to restore some UDFs manually or something ? Thanks.
>>>
>>> (Sorry if this is an RTFM, but I'm running out the door to go home
>>> and wanted to catch those on US Time zones :-) )
>>>
>>> Paul.
>>
>>
>>
>

Also, is this a really old database? Or maybe the RTRIM is applied on a
clob?

No Body wrote:

> Guys, are you sure? I thought RTRIM was changed into a built in a long
> time ago although the sysfun version should still be there.
>
> Paul, do you get the error on a clp query?
>
> Sean McKeough wrote:
>
>> Paul,
>>
>> Blair is correct, however note that for non-built udfs and stored
>> procs must be move manually after the restore (known function
>> requirement).
>>
>> Blair Adamache wrote:
>>
>>> RTRIM is part of the SYSFUN schema in v8. Perpahs you have some sort
>>> of schema issue? You should not have to install a UDF for RTRIM.
>>>
>>> Paul Reddin wrote:
>>>
>>>> Hi,
>>>> I have just successfully restored a database from one Linux box to
>>>> another.
>>>>
>>>> Unfortunately, on the restored database I get errors stating
>>>> SQL0440N No authorised routine named RTRIM of type FUNCTION
>>>> having compatible arguments was found SQLSTATE=42884
>>>>
>>>> ??
>>>>
>>>> Do I have to restore some UDFs manually or something ? Thanks.
>>>>
>>>> (Sorry if this is an RTFM, but I'm running out the door to go home
>>>> and wanted to catch those on US Time zones :-) )
>>>>
>>>> Paul.
>>>
>>>
>>>
>>>
>>
>

Sean McKeough <mckeough@nospam.ca.ibm.com> wrote:

> Paul,
>
> Blair is correct, however note that for non-built udfs and stored procs
> must be move manually after the restore (known function requirement).

I don't know the details as well as you do, Sean, but wouldn't you get a
SQL0444 in that case??

>>> SQL0440N No authorised routine named RTRIM of type FUNCTION
>>> having compatible arguments was found SQLSTATE=42884

--
Knut Stolze
Information Integration
IBM Germany / University of Jena

Hi,

I think I have fixed this issue by rebinding the CLI Packages for
Windows client (where we were seeing the error).

- Not sure why I had to do this after a restore?

The CLP (on Linux server) was working just fine, but CLI
from Windows clients wasn't.

Our Java UDFs seem to be a different issue altogether,
The Jar hasn't been restored as part of the standard restore.
- I seem to remember seeing something about this deficiency
i.e that you have to back up UDFs and SPs manually ?

I guess I'll just transfer the UDF Jar over the restore server
and perform a SQLJ.INSTALL_JAR again there?
- and maybe I have to drop/create the UDFs again too?

Thanks for the input.

Paul.

There are a few different errors that can be returned depending on the
nature of the failed lookup.

Knut Stolze wrote:

> Sean McKeough <mckeough@nospam.ca.ibm.com> wrote:
>
>
>>Paul,
>>
>>Blair is correct, however note that for non-built udfs and stored procs
>>must be move manually after the restore (known function requirement).
>
>
> I don't know the details as well as you do, Sean, but wouldn't you get a
> SQL0444 in that case??
>
>
>>>>SQL0440N No authorised routine named RTRIM of type FUNCTION
>>>>having compatible arguments was found SQLSTATE=42884
>
>

Paul,

Just re-installing the jars should be sufficient. The udf definitions
will still exist in the db (of course if you're using install_jar, you'd
have to remove/install the jar)...but really if the catalogs are there
you just need to move the jar directory from sqllib/function into the
new instance.

Paul Reddin wrote:

> Hi,
>
> I think I have fixed this issue by rebinding the CLI Packages for
> Windows client (where we were seeing the error).
>
> - Not sure why I had to do this after a restore?
>
> The CLP (on Linux server) was working just fine, but CLI
> from Windows clients wasn't.
>
> Our Java UDFs seem to be a different issue altogether,
> The Jar hasn't been restored as part of the standard restore.
> - I seem to remember seeing something about this deficiency
> i.e that you have to back up UDFs and SPs manually ?
>
> I guess I'll just transfer the UDF Jar over the restore server
> and perform a SQLJ.INSTALL_JAR again there?
> - and maybe I have to drop/create the UDFs again too?
>
> Thanks for the input.
>
> Paul.

Thanks for the input.

Some otehr underlying problems also started appearing in the restored
database, and I suddenly realised our backup machine was
on V8.1 FP2 and the restore machine was V8.1 FP1.

After upgrading the restore machine to FP2 all the gremlins
disappeared.

I was kind of surprised the restore didn't 'migrate' or 'reject'
this restore in that case ??

Paul.