SEO

#1 (**permalink**) 02-27-2008, 06:28 AM

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.

#2 (**permalink**) 02-27-2008, 06:28 AM

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

#3 (**permalink**) 02-27-2008, 06:28 AM

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

#4 (**permalink**) 02-27-2008, 06:28 AM

In article <1142978778.859716.253600@j33g2000cwa.googlegroups .com>,
michel@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)?

#5 (**permalink**) 02-27-2008, 06:28 AM

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.

#6 (**permalink**) 02-27-2008, 06:29 AM

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

#7 (**permalink**) 02-27-2008, 06:30 AM

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.

#8 (**permalink**) 02-27-2008, 06:31 AM

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,

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

SQL0818N after V7 -> V8 migration.