<< Creating an in-memory database | Persistence of properties >>

Working with Derby properties

Derby Developer's Guide

When you drop the database, Derby issues what appears to be an error but is
actually an indication of success. You need to catch error 08006, as described in "The
WwdEmbedded program" in Getting Started with Derby.

If user

authentication

and

SQL authorization

are both enabled, only the

database owner

can drop the database.

An in-memory database is automatically removed if any of the following happens:

· The Java Virtual Machine (JVM) is shut down normally (for example, if you exit the

tool)

· The JVM crashes
· The machine you are running on crashes or shuts down

Persisting an in-memory database

If you create an in-memory database and then decided that you want
to keep it after all, you can use one of the backup system procedures
(SYSCS_UTIL.SYSCS_BACKUP_DATABASE, for example) to persist it. You can
then boot it as an in-memory database at a later time, or use it as a normal file system
database. See "Backing up and restoring databases" in Derby Server and Administration
Guide for information on using the backup procedures.

Working with Derby properties

This section describes how to use Derby properties. For details on specific properties,
see the "Derby properties" section of the Derby Reference Manual.

Properties overview

Derby lets you configure behavior or attributes of a system, a specific database, or a
specific conglomerate (a table or index) through the use of properties.

Examples of behavior or attributes that you can configure are:

· Whether to authorize users
· Page size of tables and indexes
· Where and whether to create an error log
· Which databases in the system to boot

Scope of properties

You use properties to configure a Derby system, database, or conglomerate.

· system-wide

Most properties can be set on a system-wide basis; that is, you set a property for
the entire system and all its databases and conglomerates, if this is applicable.
Some properties, such as error handling and automatic booting, can be configured
only in this way, since they apply to the entire system. (For information about the
Derby system, see

Derby system

· database-wide

Some properties can also be set on a database-wide basis. That is, the property is
true for the selected database only and not for the other databases in the system
unless it is set individually within each of them.

For properties that affect conglomerates, changing the value of such properties affects
only conglomerates that are created after the change. Conglomerates created earlier are
unaffected.

Note: Database-wide properties are stored in the database and are simpler for
deployment, in the sense that they follow the database. Database-wide properties are
also recommended for security reasons when you use Derby built-in user authentication