Configuration keywords provide a convenient way to define multiple storage settings at once. One configuration keyword groups together multiple parameters and values, which specify how data and database objects are stored in the geodatabase.
You specify a configuration keyword in the following situations:
- Loading or creating datasets using ArcGIS Desktop or geoprocessing tools.
- Migrating storage types
- Building geodatabase features such as geometric networks, terrains, or topologies
ArcGIS uses the specified configuration keyword to look up the parameter name–value pairs associated with it. The values contain the configuration strings, which are incorporated in the CREATE TABLE or CREATE INDEX statement ArcGIS submits to the database.
The geodatabase is populated with default configuration keywords and parameters when it is created. New keywords can be created and values for existing parameters can be altered. You can see what configuration keyword and parameters groups are present in your geodatabase by running the Export Geodatabase Configuration Keyword geoprocessing tool, which exports all the current values to a text file. You can add keywords and parameters or alter existing parameter values and import your changes using the Import Geodatabase Configuration Keyword tool.
Default configuration keywords
The DEFAULTS, LOGFILE_DEFAULTS, and composite configuration keywords are present by default in all database management system implementations of an enterprise geodatabase. These are described in the following sections:
As the name indicates, the settings under the DEFAULTS configuration keyword are used by default when you create tables, feature classes, raster datasets, and indexes. If you do not specify a different keyword when data is created in the geodatabase, or if you specify a keyword that is missing some necessary parameters, values from the DEFAULTS keyword are used. The DBTUNE table has a fully populated DEFAULTS configuration keyword upon geodatabase creation.
When you alter the DEFAULTS keyword parameter group, you should populate it with values that represent the most common storage configuration of your data. Doing so relieves you of the need to define all the parameters for each of the keywords you define. For example, if you create a configuration keyword to create tables in a storage space segregated from the rest of the data, you only need to add the parameters that specify the tables' storage location. The rest of the parameters, such as the geometry storage type, can be picked up from the DEFAULTS keyword parameter group.
Populating the DEFAULTS keyword with the most commonly used values for your particular site also makes it easier for the people in your organization who create data. If the DEFAULTS keyword contains the settings they need for 95 percent of the data, they only have to worry about selecting a different keyword for the remaining 5 percent.
The configuration parameters initially present in the DEFAULTS keyword parameter group vary by DBMS.
Log file configuration keywords are used to control the storage of log file tables. The LOGFILE_DEFAULTS keyword is present in all enterprise geodatabase implementations; however, it is no longer used in geodatabases in PostgreSQL or SQL Server.
You can also create log file keywords for particular users so that whenever the user creates a selection set that leads to the creation of log file tables, the settings for that user's log file keyword are used. See Custom configuration keywords for details.
Composite configuration keywords
The composite keyword is a unique type of keyword used when you want to store tables from the same network, terrain, or topology class in separate spaces. You would do this, for instance, if one table is much more active than the others or if one table in the class is much larger than the others.
Composite configuration keywords are subdivided into elements: the parent element, which does not have a suffix, and the composite keyword elements, which are demarcated by the addition of the ::<element name> suffix to the parent element’s configuration keyword.
You can create composite keywords of your own, but the ones present by default are the NETWORK_DEFAULTS, TOPOLOGY_DEFAULTS, and TERRAIN_DEFAULTS composite keywords.
Network composite keywords
NETWORK_DEFAULTS is the parent keyword for the default network composite keyword. The other elements of the default network composite keyword are NETWORK_DEFAULTS::DESC and NETWORK_DEFAULTS::NETWORK. When you specify the network parent keyword, parameters and values are read from all three configuration keywords.
If you want to create your own set of network configuration keywords, replace DEFAULTS with a different word. For example, for a custom network composite keyword used for highways, you could create the following keywords:
NETWORK_HWY NETWORK_HWY::DESC NETWORK_HWY::NETWORK
As with all custom keywords, you specify the storage values you want to use for special, nondefault network classes. In this example, when you specify the NETWORK_HWY parent keyword to create a network dataset, ArcGIS uses the values set for the NETWORK_HWY, NETWORK_HWY::DESC, and NETWORK_HWY::NETWORK keywords to create the tables that make up a network.
Networks are made up of multiple system tables and feature classes. The storage parameters set for each element of the composite keyword are used to store different tables depending on the type of network and whether or not you actually specify a keyword. The following table lists which elements of the network composite keyword affect the storage of which tables in a geometric network or network dataset:
|If you...||Network composite keyword element|
Specify the network parent keyword when creating a network dataset
Defines how the system junction feature class and ND_<itemID>_DIRTYAREAS and ND_<ItemID>DIRTYOBJECTS tables are stored.
Defines how the N_<ID>_DESC table is stored
Defines the storage of all other N_<ID>_* tables
Don't specify a network parent keyword when creating a network dataset
The system junction feature class and ND_<itemID>_DIRTYAREAS and ND_<ItemID>DIRTYOBJECTS tables are created using the DEFAULTS keyword. All other network dataset tables are created using the parameters of the NETWORK_DEFAULTS parent keyword.
Specify the network parent keyword when creating a geometric network
Defines how the orphan junction feature class and build errors table are stored.
Defines how the N_<ID>_DESC table is stored
Defines the storage of all other N_<ID>_* tables
Don't specify a network parent keyword when creating a geometric network
The orphan junction feature class and build errors table are created using the DEFAULTS keyword. All other geometric network tables are created using the parameters of the NETWORK_DEFAULTS parent keyword.
For a description of geometric network and network dataset tables, see the topics for your DBMS:
- Geometric networks in a geodatabase in DB2
- Geometric networks in a geodatabase in Informix
- Geometric networks in a geodatabase in Oracle
- Geometric networks in a geodatabase in PostgreSQL
- Geometric networks in a geodatabase in SQL Server
Topology composite keywords
The topology composite keyword controls the storage of topology tables. Your geodatabase must have a valid topology keyword in the DBTUNE table for topology to be built. The topology composite keyword consists of the parent element, TOPOLOGY_DEFAULTS, and TOPOLOGY_DEFAULTS::DIRTYAREAS, which indicates where the DIRTYAREAS topology table will be stored. The DIRTYAREAS table can grow quite large and is very active in versioned geodatabases. Therefore, if your geodatabase uses topology and a lot of versioned editing takes place on the data, you should alter the parameter values of TOPOLOGY_DEFAULTS::DIRTYAREAS to store the DIRTYAREAS table components in a separate storage location; by default, they have the same storage settings as the topology table.
Be aware that datasets that participate in the same topology should use the same geometry storage type; if they do not, you may experience some topology errors due to slight variations in the way the data is stored. These variations are extremely small in most cases but could cause a violation of one or more of your topology rules.
For an introduction to geodatabase topology, see Topology basics. For a description of topology tables, see the topology storage topic for your database:
Terrain composite keywords
The terrain composite keyword controls the storage of the following tables created for terrain datasets:
ItemID is the value in the UUID field of the GDB_ITEMS table for the particular terrain dataset. N indicates the specific DTM_<itemID>_EMBED table; there can be any number (0...n) of these tables.
The default terrain keywords are TERRAIN_DEFAULTS, which controls the default storage of the first four tables listed above, and TERRAIN_DEFAULTS::EMBEDDED, which controls the storage of the DTM_<itemID>_EMBED_<N> table.
DTM_<itemID>_EMBED_<N> tables store embedded feature classes. For this reason, they could be much larger than the other terrain tables; therefore, you might want to alter the storage parameters of the TERRAIN_DEFAULTS::EMBEDDED keyword to store these tables in a different place or in a different-sized extent, depending on the DBMS you use to store your geodatabase.
For a description of the terrain tables, see the terrain storage topic for your database:
Custom configuration keywords
You might add custom keywords in the following situations:
- If a subset of your data is stored using a different spatial type or in a different location than is specified in the DEFAULTS keyword
- When setting up the system to store archiving history tables in a nondefault location.
- To have log file tables created in different areas of the database depending on which user triggers log file table creation
- To migrate to a different data type
- To specify storage locations for networks, terrains, or topologies that are different from the defaults
You edit and import a text file containing the keywords, parameters, and values you want added to the geodatabase. Be aware of the following when adding a custom keyword:
- You must prefix the keyword with two pound signs (##).
- Configuration keyword names are limited to 32 characters. If you will be creating archiving keywords, _ARCHIVE must be part of the keyword name and counts toward those 32 characters.
- If you want ArcGIS users to be able to choose or specify the keyword you create, you must include a user interface parameter.
- You must close the parameter group with END.
Follow these steps to add a custom configuration keyword:
- Create a connection to the geodatabase, connecting as the geodatabase administrator.
- Run the Export Geodatabase Configuration Keyword tool to export the existing configuration keyword values to a text file.
- Add the configuration keyword, parameters, and values you require.
- If you want people to be able to specify the keyword from ArcGIS, add the appropriate UI storage parameter to the keyword's parameter list. Use only one of the following in the same custom configuration keyword group:
- UI_TEXT: General user interface storage parameter; to be used with any keyword you want to make available to users other than log file, archiving, or network, topology, or terrain composite keywords
- UI_NETWORK_TEXT: User interface storage parameter for a parent network keyword
- UI_TOPOLOGY_TEXT: User interface storage parameter for a parent topology keyword
- UI_TERRAIN_TEXT: User interface storage parameter for a parent terrain keyword
- Save the changes you made in the text file.
- Run the Import Geodatabase Configuration Keyword tool to import the values from the text file.
Configuration keywords for archiving
You can specify configuration keywords for history tables. This is done by appending _ARCHIVE to the end of a keyword, for example, DEFAULTS_ARCHIVE. For each archive keyword you create, change the parameters as needed.
The most common use of an archive keyword is to store your history tables and the indexes on those tables in a different location than the rest of your data. Geodatabases stored in Oracle, DB2, or PostgreSQL allow you to store tables in different tablespaces; therefore, it is in these geodatabases that you would most likely use archive keywords.
When a history table is created, ArcGIS records the configuration keyword for the dataset that is being archived and searches for corresponding archive keywords. It uses the parameters specified for <keyword>_ARCHIVE when creating the history table. Therefore, if the DEFAULTS keyword is used to create a dataset that is enabled for archiving, ArcGIS will search for DEFAULTS_ARCHIVE for storage information to create the history tables for that dataset.
For any given keyword, if the corresponding archive keyword is not found, ArcGIS uses the same keyword as was used for the original dataset. In the example above, it will use the DEFAULTS keyword, which means the history tables and indexes will be stored in the same logical storage spaces as the feature class that was enabled for archiving.
If the <keyword>_ARCHIVE is present but missing a given parameter, the value of the parameter found in the DEFAULTS keyword will be used. See Geodatabase archiving for more information.
Custom log file keywords
You can create log file keywords for particular users so that whenever the user creates a selection set that leads to the creation of log file tables, the settings for that user's log file keyword are used.
You create user-specific log file keywords in the format LOGFILE_<user_name>. For example, if you want to create a log file configuration keyword for user Moe, use the keyword LOGFILE_Moe. If the connecting user name is not Moe and it does not have its own user-specific log file keyword, the LOGFILE_DEFAULTS keyword is used.
Creating a log file configuration keyword for each user allows you to store the different users' log files on separate devices. Most geodatabases function well using the LOGFILE_DEFAULTS storage parameters, but you can change the log file settings if you want.
The storage parameters you would use for this keyword depend on which type of log files the server has been configured to use. This keyword is largely a legacy keyword, and it is not used in geodatabases in SQL Server or PostgreSQL.
For more information on log file tables, see the log file topic for your database.