Just installed DB2 on Linux. I am working with it pretty much in the
dark - I don't know any of the internals yet (even such simple (?)
things like creating users that are not the same as UNIX accounts - any
pointers on that). Anyway, looks like I was able to fix all problems
and all my unit tests succeed 100%.
One last note before I go into individual problems: I noticed that JDBC
errors are actually quiet verbose, not just a bare error code. I guess
my Linux version may have a different set of default parameters.
On Wednesday, July 2, 2003, at 01:25 PM, Holger Hoffstätte wrote:
> [07-02 17:46:36 main] INFO QueryLogger: INSERT INTO ARTIST (ARTIST_ID,
> ARTIST_NAME, DATE_OF_BIRTH) VALUES (?, ?, ?)
> [07-02 17:46:36 main] INFO QueryLogger: [bind: 3, 'deleteTestArtist',
> NULL]
> ** object: null pos: 3 type: null
> [07-02 17:46:36 main] INFO QueryLogger: *** error.
> com.ibm.db2.jcc.c.SqlException: DB2 SQL error: SQLCODE: -803, SQLSTATE:
> 23505, SQLERRMC: 1;CAYENNE.ARTIST
> at com.ibm.db2.jcc.c.cl.d(cl.java:1039)
Got this one. Here is the *real* message:
Caused by: com.ibm.db2.jcc.b.SQLException: One or more values in the
INSERT statement, UPDATE statement, or foreign key update caused by a
DELETE statement are not valid because the primary key, unique
constraint or unique index identified by "1" constrains table
"ANDRUS.ARTIST" from having duplicate rows for those columns.
The real reason was that unit tests relied on this little "feature" in
other Cayenne adapters - PK generation starts from 200, so ids 1..199
are "cayenne-free" and can be used for testing purposes or whatever.
Not so for DB2. Sequence started from 1 and therefore conflicted with
rows already inserted in unit tests. I changed DB2 PK generator to
start from 200. In defense of this admittedly hackish solution (a few
people were really confused by that :-)), all I can say is that now all
adapters work the same way. No exceptions for DB2 :-). Besides this
wouldn't prevent the users to create their sequences starting from
anything they want.
> The second problem can be seen e.g. in CDOOneDep2OneTst.testReplace and
> seems to be related to BLOB and/or LONG VARCHAR insertion, although
> this
> should work as well:
>
> [07-02 17:46:46 main] INFO QueryLogger: INSERT INTO PAINTING_INFO
> (IMAGE_BLOB, PAINTING_ID, TEXT_REVIEW) VALUES (?, ?, ?)
> [07-02 17:46:46 main] INFO QueryLogger: [bind: < 02 03 04 05 >, 20,
> 'this
> painting sucks...']
> [07-02 17:46:46 main] INFO QueryLogger: *** error.
> com.ibm.db2.jcc.c.SqlException: DB2 SQL error: SQLCODE: -301, SQLSTATE:
> 07006, SQLERRMC: 1
>
Can't reproduce the second error (above) exactly; that same insert
query runs just fine for me. Although the same test case was failing in
SELECT...LIKE when casting LONG VARCHAR. I had to fix casting in the
adapter to address that.
Andrus
This archive was generated by hypermail 2.0.0 : Sun Jul 06 2003 - 22:48:25 EDT