SQL0818N after V7 -> V8 migration.

Michel Esber

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.

Mar 21 '06 #1

Knut Stolze

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

Mar 21 '06 #2

Michel Esber

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

Mar 21 '06 #3

Gert van der Kooij

In article <11**********************@j33g2000cwa.googlegroups .com>,
mi****@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)?

Mar 21 '06 #4

Michel Esber

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.

Mar 22 '06 #5

Knut Stolze

Michel Esber wrote:

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

--
Knut Stolze
DB2 Information Integration Development
IBM Germany

Mar 23 '06 #6

Ian

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.

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.

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.

Mar 23 '06 #7

Michel Esber

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,

Mar 24 '06 #8