By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,558 Members | 1,060 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,558 IT Pros & Developers. It's quick & easy.

SQL0818N after V7 -> V8 migration.

P: n/a
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
Share this Question
Share on Google+
7 Replies


P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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

P: n/a
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

This discussion thread is closed

Replies have been disabled for this discussion.