From derby-user-return-8622-apmail-db-derby-user-archive=db.apache.org@db.apache.org Tue Feb 12 00:52:16 2008 Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 4650 invoked from network); 12 Feb 2008 00:52:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Feb 2008 00:52:16 -0000 Received: (qmail 13982 invoked by uid 500); 12 Feb 2008 00:52:08 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 13953 invoked by uid 500); 12 Feb 2008 00:52:08 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 13938 invoked by uid 99); 12 Feb 2008 00:52:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Feb 2008 16:52:08 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bradm6406@hotmail.com designates 65.54.246.155 as permitted sender) Received: from [65.54.246.155] (HELO bay0-omc2-s19.bay0.hotmail.com) (65.54.246.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Feb 2008 00:51:35 +0000 Received: from BAY124-W10 ([207.46.11.173]) by bay0-omc2-s19.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Feb 2008 16:51:43 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_de3b6431-0c05-4616-96ec-32c46b1ba469_" X-Originating-IP: [68.148.155.17] From: Brad Moore To: Derby Discussion Subject: Methods for upgrading database and application Date: Mon, 11 Feb 2008 17:51:42 -0700 Importance: Normal In-Reply-To: <47B0DEFE.6060905@gmail.com> References: <200802080925.35160.daniel@nuix.com> <47ACADBD.3030603@gmail.com> <200802111010.35312.daniel@nuix.com> <47B0DEFE.6060905@gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Feb 2008 00:51:43.0135 (UTC) FILETIME=[6F6D12F0:01C86D11] X-Virus-Checked: Checked by ClamAV on apache.org --_de3b6431-0c05-4616-96ec-32c46b1ba469_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, 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 conn= ect to the central database. The latest issue I have come across is how to handle the application and da= tabase upgrades at our client sites. =20 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 applica= tion 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= work. 4. If anyone is connected to the database we abort the upgrade and info= rm the user that they should make sure all other users are disconnected bef= ore performing the upgrade. 5. If there are no users connected to the database then we rename the A= ccess file so that no users can connect to the database while we're perform= ing 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. Currently we are able to determine if anyone is connected to the Access dat= abase by just trying to rename the .mdb file. If this fails then the datab= ase 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 men= tions 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 A= ctive Sessions results to the installer program that I am using (Indigo Ros= e TrueUpdate). Is there any other method for determining the number of users that are curr= ently connected to a Derby database? Also, is there a way to lock the database so that no users can connect to i= t while the upgrade is being performed? Is there anyone else that has a similar type of situation, and how did you = handle it? Thanks, Brad _________________________________________________________________ --_de3b6431-0c05-4616-96ec-32c46b1ba469_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,

I am currently working on converting o= ur client/server application from an MS Access database to using Derby.&nbs= p; We have approximately 40 sites that use our software and each one can ha= ve from 1 to 10 client computers that connect to the central database.
<= br>The latest issue I have come across is how to handle the application and= database upgrades at our client sites. 

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

Currently we are able to determine if anyone is connected to the A= ccess 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 a= nd looking at the Active Sessions, but I don't know of a way to call that f= unction and return the Active Sessions results to the installer program tha= t I am using (Indigo Rose TrueUpdate).

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

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

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

Thanks,

Brad


<= /a> = --_de3b6431-0c05-4616-96ec-32c46b1ba469_--