From: Michel Esber on
Hello,

Linux DB2 V7 FP13 kernel 2.4.

Parts of our application login run on C++ procedures that are working
fine. I have taken an offline backup and restored it to a Linux V8
kernel 2.6 FP 14 server.

The RESTORE finished without any problem. Now when I try to call the
same procedure it returns SQL0818N (Timestamp conflict error). I have
tried to rebind the package, reinstalled the .bnd and .so files, but
nothing has worked so far.

TIA for any suggestions.

From: Knut Stolze on
Michel Esber wrote:

> Hello,
>
> Linux DB2 V7 FP13 kernel 2.4.
>
> Parts of our application login run on C++ procedures that are working
> fine. I have taken an offline backup and restored it to a Linux V8
> kernel 2.6 FP 14 server.

V8 FP11?

> The RESTORE finished without any problem. Now when I try to call the
> same procedure it returns SQL0818N (Timestamp conflict error). I have
> tried to rebind the package, reinstalled the .bnd and .so files, but
> nothing has worked so far.

What's the exact error message?

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
From: Michel Esber on
Knut, that is right. V8 FP11.

My procedure returns an integer for SQLSTATE if something ever goes
wrong. And it keeps returning SQL0818N. Unfortunately I do not have a
complete error message ...

I´ve had this problem once and all I needed to fix the issue was copy
the proper .so and .bnd files, and rebind them to the database.
However, it doesn´t seem to be that simple during migration ...

Thanks

From: Gert van der Kooij on
In article <1142978778.859716.253600(a)j33g2000cwa.googlegroups.com>,
michel(a)us.automatos.com says...
> Knut, that is right. V8 FP11.
>
> My procedure returns an integer for SQLSTATE if something ever goes
> wrong. And it keeps returning SQL0818N. Unfortunately I do not have a
> complete error message ...
>
> I?ve had this problem once and all I needed to fix the issue was copy
> the proper .so and .bnd files, and rebind them to the database.
> However, it doesn?t seem to be that simple during migration ...
>
> Thanks
>
>

Did you also rebind the DB2 util and CLI packages (db2ubind.lst and
db2cli.lst)?
From: Michel Esber on
I did rebind both packages now, but I still get the same error.
Actually, I ran a db2rbind on the database but no luck.

How do I find out which syscat.packages do these procedures correspond?
Perhaps I could delete and recreate them from scratch.

Thanks, Michel.