SQL0818N after V7 -> V8 migration.

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Michel Esber - 21 Mar 2006 22:27 GMT

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.

Reply to this Message

Knut Stolze - 21 Mar 2006 22:28 GMT

> Hello,
>
[quoted text clipped - 3 lines]
> 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?

Signature

Knut Stolze
DB2 Information Integration Development
IBM Germany

Reply to this Message

Michel Esber - 21 Mar 2006 23:06 GMT

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

Reply to this Message

Gert van der Kooij - 21 Mar 2006 23:22 GMT

> Knut, that is right. V8 FP11.
>
[quoted text clipped - 7 lines]
>
> Thanks

Did you also rebind the DB2 util and CLI packages (db2ubind.lst and
db2cli.lst)?

Reply to this Message

Michel Esber - 22 Mar 2006 14:44 GMT

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.

Reply to this Message

Knut Stolze - 23 Mar 2006 21:28 GMT

> 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.

You could have a look at the db2diag output. It should list which package
failed (with a sufficiently high DIAGLEVEL setting).

Signature

Knut Stolze
DB2 Information Integration Development
IBM Germany

Reply to this Message

Ian - 23 Mar 2006 22:45 GMT

> Hello,
>
[quoted text clipped - 8 lines]
> tried to rebind the package, reinstalled the .bnd and .so files, but
> nothing has worked so far.

I have seen 2 issues that could be related:

1) If you're using Static SQL in your procedure, and the bind file
that you provided to BIND doesn't match the compiled library
containing your stored procedure (i.e. PREP file.sqC generates
a matched pair of files (.bnd and .C). If you mix and match
these you'll get an error.

2) I have seen a similar problem in the past where the creation
timestamp for the object in question is in the future. This
makes DB2 *MAD*! Look at SYSCAT.PROCEDURES (CREATE_TIME) column
for the procedure(s) in question and see if they are in the
future. If so, try dropping and recreating your stored proc.

Reply to this Message

Michel Esber - 24 Mar 2006 16:54 GMT

All,

Prior to migration, my .bnd and .so files were compiled on a kernel 2.4
system. I have installed a new set of files (for kernel 2.6 + DB2 V8)
but the error wouldn´t go away.

The problem was solved after a bind + an instance restart.

Thanks again,

Reply to this Message