Don't put database files inside application package. Create database inside application or installation script if database not exists.
One good solution is to use Hibernate with auto-create database.


On Tue, Jan 13, 2009 at 1:39 PM, ton80 <> wrote:

Mikkel Kamstrup Erlandsen-3 wrote:
> On Tue, 2009-01-13 at 01:57 +0100, ton80 wrote:
>> I was wondering,
>> I am new to Derby.  I am working a small project in Java using Derby in
>> embedded mode.
>> Will I be able to make changes to the application and reload it without
>> affecting the data in the database?
>> I guess a better way to put the question is how do I package the
>> application
>> so that I can make changes to the application code without harming data
>> already in the database on the clients machine?
>> This may be more of a Java question.
> If you stick to the same version of Derby inside your app you should not
> have any problems. And with a little care you can also upgrade Derby
> versions...
> Of course if your different application versions require different table
> layouts inside the database your have to provide some migration strategy
> inside the app, but that does not appear to be the case as I read your
> mail.
> We are doing a lot iterative deployments using the same Derby db and we
> have not seen any problems with that.
> Cheers,
> Mikkel

Right now....without a database I just create a new jar file for the app and
install that one.
If I do that with the embedded database, I think the old DB will be
So when the app is packaged, are they seperate...or what?

This is a small application....not worth more than one jar file...unless
using this embedded database calls for a different deployment strategy.

View this message in context:
Sent from the Apache Derby Users mailing list archive at