admnew Files

Running Global Projects

Database Allocation : De-allocating a Database from a Location : admnew Files

.admnew files are created when the whole database needs to be propagated. This may occur:

•

Whenever a database is allocated to a location. The database is copied from the hub to the new location by the Global daemon. As the file is copied over the network connection, a file named

prjnnnn.admnew

is created. Once copying is complete, this file is renamed automatically to
prjnnn

For example: abc0001.admnew is created while copying, and it is renamed to abc0001 once copying is complete.

•

Whenever a primary database is merged. The next update will force the entire database to be propagated.

•

If the RECOVER command is used to recover a database from a specified location

.admnew files are self contained by the system, there should be no reason to delete them, except in extreme cases. If the daemon is running continuously and a Copy dB operation fails then the system should tidy up. Normally .admnew files are retained for later use. However, if the daemon dies (such as in a power-cut) during the process this may result in an invalid .admnew file. In this case the file should be removed from the operating system to avoid possible problems on a repeat operation.

In the case of a copy after a database has been merged, it may not be possible for the .admnew file to be renamed immediately. This will happen:

•

If there are READERS of the database ‑users are accessing an MDB which contains the database (even if they are only in MONITOR). In this case Global will not attempt to rename the .admnew file until all such users have exited or switched to an MDB which does not include the database. Once all such users have exited, the copy will normally succeed.

•

If the database is locked by a ‘Dead’ user ‑ a session for a user which has been expunged. In this case Global attempts to rename the .admnew file, but it fails.

To resolve the second situation, one of the following must be done: either

•

Make sure that the sessions for all ‘dead’ users have been killed. Also make sure that no foreign projects are reading this database; or

•

Use the NET FILE command in a ‘cmd’ window (or a suitable third party tool) to identify network access to the file, and close it.

If the project is not used as a foreign project, there is an additional alternative. The Overwrite DB Users flag ‑ the attribute LCPOVW of the LOC element - for a location controls whether a ‘locked’ file may be overwritten. If this attribute is set TRUE and there are no database READERS in the project, then Global will overwrite the ‘locked’ file by the .admnew file.

Note:

This should not be done if other projects include this database as a foreign project, since these are valid READERS that are not recorded in the session data for the Global project.

Overwriting of locked databases may be enabled by using the ‘MODIFY’ dialogue for the location on the Admin Elements window to enable Overwriting, or by setting LCPOVW TRUE for the appropriate LOC element on the command-line.

See also Database File Locks.

1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.