FAQ: How are updates to event layers handled in ArcMap Server?
How are updates to event layers handled in ArcMap Server?
When adding event layers via data stored in a dbf file, ArcMap server should automatically assign a unique object id (OID) to each event. The OID is required by ArcMap server to select event features.
When working with event layers by way of data stored in an ArcSDE/database, a few additional steps must be taken. A non-spatial, unregistered (ArcSDE) database table can be used as an event layer, but the event features are not selectable. In order to select the features, they must have an OID.
There are two methods for adding an OID to an event layer via ArcSDE:
- ArcSDE maintained
- User maintained
When registering a database table using ArcCatalog, it automatically adds an ArcSDE-maintained OID column. Since ArcSDE is responsible for maintaining this column, updates must occur within an ESRI product such as ArcCatalog, ArcObjects or the ArcSDE API. This verifies that the appropriate geodatabase events are triggered.
If any updates occur outside an ESRI product, for example by way of SQL, problems may occur because ArcSDE and the geodatabase are unaware of the change. In this case, a user-maintained OID column should be defined. This column must be integer, not null, and unique. An existing column can be used as long as the contents adhere to these restrictions.
A user maintained OID can be set using the sdetable command. For example:
>sdetable -o register -t dynseg_events_reguser -c userid -C USER -u ims -p ims
where 'userid' is the OID column name and 'USER' tells ArcSDE to let the user's application modify the OID column.
Unregister the table before reregistering with the user-maintained column.
By default, ArcMap server caches event data. An EventSource, also an event layer, relies on the events fired by the geodatabase object model to know when to update itself.
If the event table is edited by an application that causes the geodatabase events to be fired; for example, ArcMap, a client application; for example, ArcIMS, recognizes the changes and the cache is updated.
If the event table is being edited by software that does not cause the geodatabase events to be fired; for example, SQLPlus, the client application does not recognize that changes have been made and uses cached event data. To view the changes the application must be restarted or refreshed. The 'UseOptimization' registry value on the ArcIMS spatial server, also ArcMap Server, machine defines whether or not event data is cached on the client.
Under the 'DynSeg' key, set the 'UseOptimization' DWORD decimal value to 0 to disable the cache. When the cache is disabled, an ArcIMS ArcMap service recognizes updates and inserts them to an event layer without needing to refresh the map service. The default value is 1, specifying that the cache is turned on, in which case the map service must be refreshed in order to see the changes.
ArcMap Server included with ArcIMS 4.0.1 does not use this registry key, therefore the cache is always turned on. When editing the event layer table in an application that causes the geodatabase events to be fired, the ArcMap service recognizes the changes. However, when using a non-ESRI application, the ArcIMS ArcMap service must be refreshed in order to see the changes reflected in the service.
- Does ArcMap Server support Event Layers?
- Selection from ArcMap Service event layer features using HTML client does not render
- Cannot view ArcMap Service event layer features using Java client