Hi Laura,
Sorry missed your mail.
Yes I agree the step of manually updating the CLASSPATH to the latest
jars will be useful. Worthwhile
to mention that the Derby version should be verified once the CLASSPATH
is updated to make sure
no other older versions of Derby jars exist.
Regards,
Rajesh
Laura Stewart wrote:
On 9/22/06, Rajesh Kartha <[EMAIL PROTECTED]> wrote:
Upgrade in Derby is just booting the old db with newer Derby jars in the
CLASSPATH and passing the
appropriate properties in the url.
However, I do agree the current location for determining the Derby
version does seem a bit strange and given the choices
I think this could go to the "Preparing the upgrade" under a sub
section say "Determining the Derby version"
or something related.
And possibly adding a line to check the Derby versions being upgraded
from and to to be make things clearer (?).
http://db.apache.org/derby/docs/dev/devguide/tdevpreupgrade.html
Something like:
Before connecting with the new software:
Back up your database to a safe location using Derby online/offline
backup procedures. For more information on backup, see the /Derby Server
and Administration Guide/. *Please
check the Derby version being upgraded from/to*. If you do not perform a
soft upgrade, then once the database is upgraded, it cannot be reverted
back to the previous version.
-Rajesh
Hi Rajesh -
What seems to be missing is thta step to update the CLASSPATH with the
new version of the jar files. I assume that this must be manually
done by the user?
