Home/ Questions/Q 8383943
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T17:17:41+00:00

I’m not sure what is going on with my derby database, but I seem

  • 0

I’m not sure what is going on with my derby database, but I seem to have tables that I can can see from the ij interface…

ij> show tables in derbytest;
TABLE_SCHEM         |TABLE_NAME                    |REMARKS
------------------------------------------------------------------------
DERBYTEST           |DATATYPETEST                  |
DERBYTEST           |LOCATION                      |
DERBYTEST           |SUIVI                         |

now I get the tables description…

ij> describe derbytest.datatypetest;
COLUMN_NAME         |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL&
------------------------------------------------------------------------------
A_DATE              |DATE     |0   |10  |10    |NULL      |NULL      |NO
AN_INT              |INTEGER  |0   |10  |10    |NULL      |NULL      |YES
A_DECIMAL           |DECIMAL  |0   |10  |5     |NULL      |NULL      |YES
A_STRING            |VARCHAR  |NULL|NULL|20    |NULL      |40        |YES
A_SWITCH            |BOOLEAN  |NULL|NULL|1     |NULL      |NULL      |YES

So I guess the table exists, but…

ij> select * from derbytest.datatypetest;
ERREUR XSAI2 : Le conglomÚrat (1á232) demandÚ n'existe pas.

So a quick check to see if the problem is being caused by an ’empty’ table..

ij> select * from derbytest.suivi;
OBS        |DATE                         |TIME
-----------------------------------------------------------------------

which to me suggests not!

I’m not sure I fully understand the implication of the error message, i found this in the docs

Table 36. Class XSAI: Store – access.protocol.interface SQLSTATE
Message Text XSAI2 The conglomerate () requested does not
exist.

which isn’t amazingly helpful!
I’ve had a look at the various API docs for the engine, language, testing and tools, but I don’t know where to start to look, any pointers would be helpfull.

It may be related to how I am setting the database, so some quick background.

I connecting to this test DB from a java test class. It gathers info from another datasource (XL of flat file) then drops it into this database (or that is the aim). I am only showing a small ‘test’ that I may to ensure my connection was working.

I have another schema in this file that has more tables, and they all have this same problem.

Have I not correctly closed a conection and lost data?
Have I somehow inadvertently delected a data file, that contained the missing ‘conglomerate’

Any help is greately appreciated.

David.

ps I have other test DB’s that I haven’t checked to see if they have the same problem.
I’m running java 6 on XP.

edit1: Just checked the other testDB I am using, it contains no tables! I obviously cleaned up after myself. Now where did that cat go ??

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    That is odd behavior, to be sure. I’m not sure what’s wrong.

    Did you create your table inside a transaction but not yet commit that transaction?

    Did you create your table using an in-memory database, in which case it disappears when you close the database?

    Did you create your database in one location on the disk, then later connect to a different location with ‘create=true’, in which case Derby creates a new blank database in the new location?

    Did you create your database using one schema, then connect with a different schema?

    The error message does suggest some internal damage to the table. The number in parentheses (1a232) is a conglomerate number, which is also used to identify the conglomerate’s filename in your filesystem. So you could look in the filesystem and match up the files that are there to the tables in your database (by selecting from sys.sysconglomerates).

    You get a conglomerate for the table itself, plus additional conglomerates for each secondary index, both those created by CREATE INDEX and those created by implicit constraints such as UNIQUE or REFERENCES.

    If you suspect you have table damage, it’s best to restore from a backup. Did you experience any system crashes, disk full events, etc., which might have indicated table damage?

    • 0