db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: Different DB behavior loaded from JAR vs. file system
Date Thu, 03 Dec 2009 12:35:35 GMT
malesch wrote:
> I checked again, altough I was quite sure, I only connect as the user
> "app" (I have no other users).
> In every case "values CURRENT_USER" always return "APP" and the second
> query always the
> schema name "APP" with the corresponding "table name".
> I realized that I previously wrote nonsense because not tables are
> missing (what would lead to
> a user problem) but rows in a table...

Did you shut down the database properly before jarring it up?
I'm not sure what happens with a JAR database if there are unprocessed 
transaction logs in the log directory, but since access is read-only a 
guess would be that the logs are simply ignored.

If the logs are there, but not processed when the db is in a jar, they 
will be processed on start-up when you unzip the JAR and connect to the 

To make sure the database is in a clean state before you jar it up, shut 
it down properly: 'jdbc:derby:mydb;shutdown=true'


> Kathey Marsden wrote:
>> malesch wrote:
>>> . I realized that
>>> in my demo with the extracted DB (on the file system) the expected
>>> tables didn't show up (like in the JAR case). Disappointed I opened the
>>> same DB with SquirellSQL and, surprise, the tables were there again.
>>> After this opening with SquirellSQL my demo programm showed again the
>>> previously missing tables.
>> I know this was suggested before and perhaps you checked already, but
>> it sounds a lot like you are not connecting with the same user each
>> time.  The schema for the table creation will match the user name.  A
>> couple of queries to get your bearings:
>> values CURRENT_USER
>> select schemaname, tablename  from sys.sysschemas s, sys.systables t
>> where NOT tablename like  'SYS%' and s.schemaid  = t.schemaid;
>> If your table schema and user don't match you can either log in as the
>> matching user or select with the fully qualified name e.g.
>> select * from kathey.t;

View raw message