De-allocation

When a database is no longer needed at a Satellite, it can be De-allocated.

• The user cannot de-allocate a primary database: first change the primary location. If you make a database secondary while a user is writing to it, the user will be able to write to the database until a module change or a GETWORK. The database will not be re-allocated until the user quits or changes to an MDB that does not include that database.

• The user cannot de-allocate a database from a location which is the parent of the primary location. A database must be allocated to all locations between the Hub and its primary location.

• If users are reading a database at a Satellite when it is de-allocated from that location, then the database will not immediately be deleted from the Satellite. The de-allocation transaction will be stalled until all users at the location exit their sessions or change to an Multiple Database (MDB) that does not include the database. The database will then be de-allocated and the database files deleted. (However a location can still be deleted even if it still has its transaction database allocated).

  Note:
  Under normal circumstances, do not de-allocate a Satellite’s transaction database from the Satellite. This facility is only provided for recovery purposes, or to allow a Satellite to be deleted.

Refer to What Happens When Databases are Allocated for a description of the allocation and de-allocation mechanism. (Refer to Command Reference, DEALAL and DEALDB attributes.)

The procedure for de-allocating a database is shown in the following diagram: