From: Michel Esber on 21 Mar 2006 16:27 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 21 Mar 2006 16:28 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 21 Mar 2006 17:06 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 21 Mar 2006 17:22 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 22 Mar 2006 08:44 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.
|
Next
|
Last
Pages: 1 2 Prev: DB2 SQL error: SQLCODE: -805, NULLID.SYSLH20A 0X5359534C564C3031 Next: NULLID.SYSSN300 |