Tag Archives: geodatabase
As a support analyst, we get a range of fun issues to review. These issues may be specific to the user’s environment, data, workflow, etc. Sometimes, we may notice an influx of calls pertaining to a single workflow. When this happens, we revisit the resources our users have available to them, and ensure that the documentation clearly describes how to execute workflows.
One of these workflow issues we have seen in the call center lately has been working with schema changes in replicas. For example, after creating a replica, you realize you need to add a field to a certain feature class, or remove a domain that is no longer necessary. This blog hopes to make this workflow more intuitive with a few tricks that will help the replica gurus out there efficiently deal with schema changes. Continue reading
In a versioned environment, all edits are stored in what we call delta tables, or Adds and Deletes tables, and these tables are assigned to a unique state ID. Edits are held in the delta tables to handle any conflicts in a multi-user enterprise geodatabase. A compress operation trims the delta tables of any unreferenced state ids, consolidating the states lineage down to one state. If a state is still being referenced, it will remain in the delta tables, resulting in a partial compress.
In a fully compressed geodatabase, there are no rows in the delta tables, and the state tree is trimmed back to one state, state_id=0. Although a full compress is ideal, it is not always necessary and in some cases may not even be practical. For example, if there are many multi-generation replicas in your geodatabase that are not unregistered before the compress, you will need to send changes for all of these replicas to achieve a full compress. If there are many Two-way replicas, and you intend to fully compress both the parent and the child geodatabases, this process of synchronization will need to be done separately from both geodatabases, even if there are no changes to be sent.
Query layers were first introduced at the 10.0 release primarily to allow ArcMap to integrate data from databases that do not contain the system geodatabase repository tables. Think of query layers as a method for accessing database objects that are not … Continue reading
If you are a customer with an Oracle geodatabase and are planning to upgrade your enterprise geodatabase to ArcGIS 10.2.1, please read the following technical article before you upgrade, as some issues exist that directly impact the upgrading process. If you have any further … Continue reading
With the release of 10.2 and plans to deprecate the ArcSDE command line tools, you may be wondering how current tasks that use these tools can be completed elsewhere. I wanted to share some workflows that have alternate user interface … Continue reading
With the growing need for organizations to distribute their data in remote locations, geodatabase replication can help to manage the changes made between geodatabases in different locations. When working with distributed and remote geodatabases it is often asked, “What is the best method to create and setup replicas?”
Tuning your RDBMS is an important aspect of maintaining your enterprise geodatabase. Two tasks found in all Esri-supported RDBMS are updating DBMS statistics and rebuilding indexes. If you are loading data in bulk or running query-intensive DML operations with SQL, these tasks need to be done more often. Fortunately for us, these tasks are relatively straightforward to accomplish.