Thank you all At the end - taking care for the version of derby to be the same when I build the database or when I search - deleting the old database (corrupted) and starting with a new one, then creating the table and populating it Solved the problem.
Archiving the database in a jar was not the reason. Cheers François -----Original Message----- From: Rick Hillegas <[email protected]> Sent: 12 September 2020 18:13 To: RAPPAZ Francois <[email protected]> Cc: [email protected] Subject: Re: database in a jar : conglomerate does not exists This error indicates that you are trying to boot a database with a lower version of Derby than the one used to create the database. I believe you said that the database was created by Derby 10.8.2.2. It looks like you are trying to boot it with some version of Derby in the 10.4 family. -Rick On 9/11/20 12:33 AM, RAPPAZ Francois wrote: > If I start from a new database (named docentries), I packed it in a jar, I > can connect with ij and run a select command. > > If I run the code from my java classe, I get the error > > ----- SQLException ----- > SQL State: XJ040 > Error Code: 40000 > Message: Failed to start database 'classpath:docentries', see the next > exception for details. > > ----- SQLException ----- > SQL State: XCL20 > Error Code: 20000 > Message: Catalogs at version level 'null' cannot be upgraded to version > level '10.4'. > > I connect with db = new > DBConnector("jdbc:derby:classpath:docentries"); > > François > > -----Original Message----- > From: Rick Hillegas <[email protected]> > Sent: 11 September 2020 00:49 > To: Derby Discussion <[email protected]>; RAPPAZ Francois > <[email protected]> > Subject: Re: database in a jar : conglomerate does not exists > > Also, look inside the jar file for a directory called docentries/seg0. > Does it contain a file called c560.dat? > > On 9/10/20 8:53 AM, Rick Hillegas wrote: >> Sorry. Make that query: >> >> SELECT s.schemaName, t.tableName, c.conglomerateName >> >> FROM sys.sysConglomerates c, sys.sysSchemas s, sys.sysTables t >> >> WHERE c.conglomerateNumber = 1376 >> >> AND c.tableID = t.tableID >> >> AND t.schemaID = s.schemaID >> >> ; >> >> >> On 9/10/20 8:22 AM, Rick Hillegas wrote: >>> Hi François, >>> >>> Do you have any information or theories about how your database >>> became corrupted? I have never encountered this situation before. A >>> database in a jar file should be read-only, so the only theory I >>> have is that the jar file itself was corrupted by some process outside >>> Derby. >>> >>> Please run the following query in order to find out what table/index >>> is corrupted: >>> >>> SELECT s.schemaName, t.tableName, c.conglomerateName >>> >>> FROM sys.sysConglomerates c, sys.sysSchemas s, sys.sysTables t >>> >>> WHERE c.conglomerateNumber = 376 >>> >>> AND c.tableID = t.tableID >>> >>> AND t.schemaID = s.schemaID >>> >>> ; >>> >>> >>> Thanks, >>> -Rick >>> >>> On 9/10/20 3:09 AM, RAPPAZ Francois wrote: >>>> Hi >>>> I have a one table database embedded in a jar file. I tried to >>>> access it from ij with java -jar %DERBY_HOME%/lib/derbyrun.jar ij >>>> -p ij.properties >>>> >>>> ij.properties is >>>> derby.ui.codeset=utf8 >>>> ij.connection.doc=jdbc:derby:jar:(U:/docs/OA/articles/zlib/autconv/ >>>> a >>>> utconv.jar)docentries >>>> >>>> >>>> I can see that my table (authors) is in the the database with SHOW >>>> TABLES; I can see the columns >>>> ij> DESCRIBE authors; >>>> COLUMN_NAME >>>> |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL& >>>> ------------------------------------------------------------------- >>>> - >>>> ---------- >>>> >>>> NAME1 |VARCHAR |NULL|NULL|20 |NULL |40 |NO >>>> NAME2 |VARCHAR |NULL|NULL|20 |NULL |40 |NO >>>> DATA |VARCHAR |NULL|NULL|50 |NULL |100 >>>> |YES AUTHOR_ID |INTEGER |0 |10 |10 |AUTOINCRE&|NULL >>>> |NO >>>> >>>> 4 rows selected >>>> But I can't run a select statement: >>>> ij> select * from authors; >>>> ERROR XSAI2: Le conglomerat (1,376) demande n'existe pas. >>>> ij> exit; >>>> >>>> I have derby 10.8.2.2 >>>> Thanks for any help. >>>> >>>> François >>>> >>> >> > .
