General Advice
As with the ObjectScript commands SET, MERGE, KILL, and others, the tools described here provide direct access to manipulate globals. If you delete or modify via global access, you bypass all object and SQL integrity checking and there is no undo option. It is therefore important to be very careful when doing these tasks. (Viewing and exporting do not affect the database and are safe activities.)
Caution:
Globals that are part of an extent are managed by corresponding ObjectScript and SQL code. Any changes made to such a global through direct global access may corrupt the structure of the global (rendering its data inaccessible) or otherwise compromise access to its data through ObjectScript or SQL.
To prevent this, you should avoid use the kill command on globals for tasks like dropping all the data in an extent. Instead, you should use API methods such as %KillExtent()Opens in a new tab or TRUNCATE TABLE, which perform important maintenance, such as resetting associated in-memory counters. However, classes that use a customized storage definition to project data from globals, are fully managed by application code, are exceptions to this rule. In such classes, you should consider setting either READONLY to 1 or MANAGEDEXTENT to 0 or both.
When using the tools described in this topic, make sure of the following:
-
Be sure that you know which globals InterSystems IRIS® data platform uses. Not all of these are treated as “system” globals — that is, some of them are visible even when you do not select the System check box. Some of these globals store code, including your code.
See Global Variable Names to Avoid.
-
Be sure that you know which globals your application uses.
Even if your application never performs any direct global access, your application uses globals. Remember that if you create persistent classes, their data and any indexes are stored in globals, whose names are based on the class names (by default). See Data.
