Thanks for letting us know how you resolved the issue.
On 9/14/20 11:08 PM, RAPPAZ Francois wrote:
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 <rick.hille...@gmail.com>
Sent: 12 September 2020 18:13
To: RAPPAZ Francois <francois.rap...@unifr.ch>
Cc: derby-user@db.apache.org
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 <rick.hille...@gmail.com>
Sent: 11 September 2020 00:49
To: Derby Discussion <derby-user@db.apache.org>; RAPPAZ Francois
<francois.rap...@unifr.ch>
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
.
