REMOTE (Global Project Administration)
- Last UpdatedJan 30, 2025
- 7 minute read
Function:
Allows the Hub or the administering Location of a Satellite to carry out the following tasks for constructor or System Databases (DB) at a Satellite:
Other than when the REMOTE . . . CHECK command is used, the DBs must be Primary at the destination Satellite.
Note:
REMOTE MERGE should be considered as a Global merge, since it affects all available Locations
to which the DB is allocated, including its Secondary Locations.
At Global 12 the administrator can perform Queries on the REMOTE function to allow reporting on session details and other file details for remote Satellites.
The REMOTE . . . BACKTRACK, REVERT, MERGE CHANGES and EXPUNGE commands can be given at the Hub, the Satellite itself or the administering Location. The Satellite itself may need to use the REMOTE version of the command, because it may not have write access to the System DB. The administering Location may need to use the REMOTE version of the command, because it may not have write access to the constructor DB.
The REMOTE . . . CHECK command can be given at any Location.
Certain REMOTE commands cannot be used for extract DBs.
Note:
The difference between the REMOTE options, and centralized administration of a Satellite, are that REMOTE commands are executed by the Global daemon, rather than by the AVEVA base product.
All daemon commands take time to complete, and generally the administrator will need
to wait for this to happen.
-
The REMOTE commands (other than CHECK) can only be applied to DBs which do not own extracts, and to leaf extracts.
-
REMOTE . . . BACKTRACK, MERGE CHANGES and EXPUNGE commands will not take effect while there are Users (or potential Users, for example, in MONITOR) in the Project.
-
REMOTE . . . BACKTRACK will do nothing if the Primary Location of the DB contains later sessions than the Secondary DB at the issuing Location. It will not backtrack through stamped sessions. The DB must be allocated at the issuing Location in order to determine the latest session there.
-
If the Primary DB at the Satellite contains later sessions than the Secondary DB at the Location issuing the command, the REMOTE . . . MERGE CHANGES command will not merge the later sessions. (If the DB is non-propagating, later sessions will be merged.) REMOTE MERGE will not remove stamped sessions. Unless the DB is non-propagating, it must be allocated at the issuing Location in order to determine the latest session there.
-
Global merging (syntax REMOTE MERGE) also merges the DB at Secondary Locations after it has been merged at the Primary Location in order to prevent unnecessary copying of the entire DB when it is next updated. This means that the command may take some time to complete.
-
The administrator is advised to stop scheduled updates and avoid adhoc updates until the entire Global merge command (syntax REMOTE MERGE) has completed for the DB. If scheduled updates are left in place, then unnecessary copying of entire DBs will be undertaken, and changes made by Users at the Primary Location may be lost.
-
The parameter syntax REMOTE <loc> MERGE CHANGES GLOBALDB where <loc> is the Project Hub can be used to merge a Global DB. The REMOTE MERGE command can be scheduled by using the AT parameter show in the following examples.
-
The REMOTE . . . CHECK command can be given at any Location on any DB. Both Primary and Secondary DBs can be checked. This command runs the stand-alone Data Integrity Checker (DICE) on the specified DB from the daemon at the specified Location and reports back to the Location that issued the command.
-
However, extract DBs cannot usefully be checked in isolation (using CHECK FILE), since access to the extract owner is required. This means that REMOTE CHECK cannot be used on extract DBs other than the extract master
-
The administrator can also query information about the Project status at a Satellite. For further information, refer to Querying.
-
REMOTE EXPUNGE cannot distinguish between genuine and dead Users of a DB at a Location. The System administrator should use remote session information to check which Users are actually writing to the DB. For further information, refer to Querying.
-
REMOTE MERGE and REMOTE BACKTRACK are not valid for extracts which own other extracts. However, REMOTE REVERT and REMOTE EXPUNGE can be used. A DB that owns extracts must be merged in the AVEVA base product using the MERGE command.
Examples:
For details of time and date syntax, refer to Notes on Syntax Graphs for further information.
|
BACKTRACK: |
|
|
REMOTE <loc> BACKTRACK dbname TO 14:30 REMOTE <loc> BACKTRACK dbname TO SESS 17 Backtracks changes to the given DB, which must be Primary at the named Location. A DB cannot be backtracked through a Stamp. |
|
|
REVERT: |
|
|
REMOTE <loc> REVERT dbname TO 14:30 REMOTE <loc> REVERT dbname TO SESS 17 Adds a session reverting to the data at the specified session or date. The DB must be Primary at the named Location. |
|
|
MERGE CHANGES: |
|
|
REMOTE <loc> MERGE CHANGES dbname BEFORE 31 MARCH REMOTE <loc> MERGE CHANGES dbname BEFORE SESSION 9 AFTER SESSION 4 Merges changes to the given DB, which must be Primary at the named Location. Stamped sessions will not be removed by the merge. REMOTE <loc> MERGE CHANGES SYSTEM Merges changes to the System DB for the Location <loc>. |
|
|
REMOTE <loc> MERGE CHANGES SYSTEM FOR <loc2> Merges changes to the System DB for <loc2>, which must be administered by <loc>. REMOTE <loc> MERGE CHANGES <dbname> AT 23:00 <merge-options> Merge changes at a specified time, in this case at 23:00 hours. Where <merge-options> are the normal Before/After session information described above. |
|
|
REMOTE <loc> MERGE GLOBALDB Merges the Global DB at Location <loc>. |
|
|
EXPUNGE: |
|
|
REMOTE <loc> EXPUNGE REMOTE <loc> EXPUNGE username Expunges all Users or the given User from the Comms DB at the given Location. username is the AVEVA base product username. |
|
|
REMOTE <loc> EXPUNGE DB dbname Expunges all Users or the given User from the given DB at the given Location. The DB must be Primary at the given Location. username can be the AVEVA base product username or a session number. |
|
|
REMOTE <loc> EXPUNGE DB dbname AT 22:55 Expunges the specified DB at a specified time, to allow housekeeping operations. |
|
|
DICE Checking: |
|
|
REMOTE <loc> CHECK SYSTEM Performs a stand-alone DICE check on the given DB at the given Location. The DB does not need to be Primary at the given Location. The check uses the current MODE, STATISTICS, MAXERRORS and MAXWARNINGS settings. |
|
|
Cancelling commands: |
|
|
REMOTE <loc> CANCEL <gid> Allows an Admin User to cancel a command at another Location <loc>, where <gid> is a TRINCO in the transaction DB for the given Location (this is not the current Location, unless <loc> is the current Location). This command requires an up-to-date version of the transaction DB for Location <loc> to be available at the current Location. (The transaction DB is not normally propagated. It is best to use the RECOVER command to recover this DB from the Primary Location rather than to use SYNCHRONIZE.) |
|
Note:
Only commands which have not started can be cancelled.
Command Syntax:
For details of <loc> and <when> syntax, refer to Notes on Syntax Graphs for further information.
|
>- REMOTE <loc> BACKTRACK dbname TO <when> --> >- REMOTE <loc> REVERT dbname TO <when> --> >- REMOTE <loc> MERGE CHANGES +--- dbname ----------------. +--- GLOBAL ----------------| .---------. +--- SYSTEM -+- FOR <loc> --| / | `--------------+--+-<options>-+ `---> where <options> is:---+--BEFORE <when>---. +--AFTER <when>----| +--AT <date>-------| `------------------+---> REMOTE (continued) >- REMOTE <loc> EXPUNGE -+- USER username ----------------------. >- REMOTE <loc> CHECK --+-- DB dbname ------------------------. |
Querying:
Remote DB session information can be queried using the Q REMOTE command.
|
Q REMOTE <loc> <dbname> FILEDETAILS Would return: Compaction number 104 Last session 142 Header changes count 0 Claim list changes count 0 Last page 139 |
|
Q REMOTE <loc> <dbname> LASTSESSION Would return: Session 142: Date: 14:52 04 Feb 2009 User: fred.bloggs Description: Default session comment |
Note:
When used in syntax for variables, the data from the query is returned in CSV format,
suitable for export to a spreadsheet (this applies to both FILEDETAILS and LASTSESSION).
The success of DB updates may be monitored using these queries. These allow comparison of the state of the DB at different Locations.
Where <dbname> can be one of:
-
Global
-
System
-
System for Local
-
System for <loc>
The Global banner at a remote Location can be queried using:
Q REMOTE <loc> BANNER
An example output would be:
AVEVA Global Mk12.0.0.1 (WINDOWS-NT 5.1) (Mar 6 2009)
Information about remote Users of the AVEVA base product may be queried using remote session objects. For example:
|
!p = current Project |
Returns a Project object. |
|
!l = !p.Locations() |
Returns an array of Location objects. |
|
!r = !l[2].sessions() |
Returns an array of session objects for the specified Location. |
|
Only the following session object methods are valid for a session at a remote Location (where !l[2] is not the current Location). |
|
|
q var !r[1] |
The below example output is the Daemon itself: <SESSION> 149c-PC526 ENTERED <STRING> '10:09:26 Tue, 3 Mar 2009' HOST <STRING> 'PC526' ISCURRENT <BOOLEAN> FALSE ISREMOTE <BOOLEAN> TRUE LOCATIONNAME <STRING> '/LONDON' LOGIN <STRING> 'SYSTEM' NAME <STRING> 'globaldaemon - Global Daemon' UNIQUEID <STRING> '149c-PC526' |
|
q var !r[1].module() |
Example of user() query (from the above session): <STRING> 'GLOBALDAEMON'; |
|
q var !r[1].user() |
E.g. (from the above session): <USER> SYSTEM ACCESS <STRING> 'Free' DESCRIPTION <STRING> '' NAME <STRING> 'SYSTEM' REFNO <STRING> '=24575/668' |
|
q var !r[1].mdb(). |
E.g. (from the above session): <MDB> Unset - Unset DESCRIPTION <STRING> Unset NAME <STRING> Unset REFNO <STRING> Unset We can thus query which MDBs which Users are using in which modules at Location <loc>. |
This may be combined with information about the Satellite MDBs to identify Users of a DB when using REMOTE . . . EXPUNGE.
For more information about PML Objects, refer to Software Customization Reference. Only these three session methods are available for remote sessions.
Related Commands:
CANCELCOMMAND (Global Project Administration)
REMOTEMESSAGE (Global Project Administration)
MERGE CHANGES (Project Administration)
REVERT (Project Administration)
BACKTRACK (Project Administration)