db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnny Kewl" <j...@kewlstuff.co.za>
Subject Re: Methods for upgrading database and application
Date Tue, 12 Feb 2008 10:23:53 GMT

HARBOR: http://coolharbor.100free.com/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
Making the Java dream come true.
----- Original Message ----- 
From: Brad Moore
To: Derby Discussion
Sent: Tuesday, February 12, 2008 2:51 AM
Subject: Methods for upgrading database and application


I am currently working on converting our client/server application from an 
MS Access database to using Derby.  We have approximately 40 sites that use 
our software and each one can have from 1 to 10 client computers that 
connect to the central database.

The latest issue I have come across is how to handle the application and 
database upgrades at our client sites.

Our current process is automated and works like this:
    1. Check on our website to see if there is a new release available
    2. If there is a new release available, download the new client 
application and the scripts to upgrade the database
    3. Determine if anyone is currently connected to the database prior to 
performing the upgrade so we are not altering tables while someone is doing 
    4. If anyone is connected to the database we abort the upgrade and 
inform the user that they should make sure all other users are disconnected 
before performing the upgrade.
    5. If there are no users connected to the database then we rename the 
Access file so that no users can connect to the database while we're 
performing the upgrade.
    6. Perform the database upgrade.
    7. Rename the Access database file back to it's original name so it is 
available for use again.
    8. Upgrade the client application files.

Brad MS Access is the best prototyping tool in the world, and the worst 
I vaguely remember writing tons of code to make it user friendly, getting 
around exclusive locks
and other stuff

It sounds like a big system you have there, and I think you should also look 
at big
systems like Postgres

I say this becaus I'm not sure of Derby's ODBC support, I dont know if there 
is an official
driver... and coming from MS I think you "better" make sure that works well.

On Postgres using MS Access as a frontend works, I not sure thats Derby's 

Coming from MS Access, I think you thinking small... on these big dB's 
things like worrying about
users in the dB before you start routing maintenance... is done for you.
Setting flags that say... when all the users are finished, lock down the 
dB... are just flags

Also in most area's now the bigger dB's are MS friendly (Run Setup) but
can also do linux

Derby is a great dB... and its hard to classify them... but making an 
application that needs
embedded dB (Derby is great), making an Accounting application where a 
networked dB
just falls out of the JRE... Derby and Sun make it easy..

Aim at sitting in your control tower... and just doing it all, no more 
download, and users banging their head.
The user mustnt even know you in the dB and changing stuff...
Running 10 branch offices.... do you homework is all I wanted to say....


Currently we are able to determine if anyone is connected to the Access 
database by just trying to rename the .mdb file.  If this fails then the 
database is in use.  I have been unable to find a good way to determine if 
there are any users currently connected to the Derby database.  I have found 
mentions of calling NetworkServerControl runtimeinfo and looking at the 
Active Sessions, but I don't know of a way to call that function and return 
the Active Sessions results to the installer program that I am using (Indigo 
Rose TrueUpdate).

Is there any other method for determining the number of users that are 
currently connected to a Derby database?

Also, is there a way to lock the database so that no users can connect to it 
while the upgrade is being performed?

Is there anyone else that has a similar type of situation, and how did you 
handle it?



View raw message