Esri Technical Support Blog

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Other Boards in This Place

Latest Activity

(383 Posts)
New Contributor III

Exciting things are coming for GIS users in 2018 - ArcGIS Desktop 10.6 and ArcGIS Pro 2.1 are being released in January, along with some great new tools, features and functionality. Esri Technical Support is excited to work with our customers in these new environments, but what does this mean for some of the older platform versions?

Alas, on January 1, 2018, ArcGIS 10.1 is officially retired

Here's a quick list of what this entails: 

  • Technical Support will not be available for ArcGIS Desktop 10.1, ArcGIS Server 10.1, or Enterprise GDBs at 10.1
  • It will not be possible to request a Support Case for ArcGIS Desktop/Server/Enterprise 10.1
  • We are here to help you with upgrading. If you need technical support for the upgrade process, give us a call. 

As this year comes to a close, it's important to plan ahead. Get a jump start on upgrading your applications and geodatabases, and reach out to us if you have questions. 

For more information, check out some of our documentation:

Product Life Cycle for ArcGIS 10.1

Deprecation Plan for ArcGIS 10.1 and ArcGIS 10.1

3 3 1,415
New Contributor III

With the release of ArcGIS 10.4 comes a brand new geoprocessing tool that allows you to update your enterprise geodatabase license efficiently through ArcGIS for Desktop. The Update Enterprise Geodatabase License tool is now included in the Geodatabase Administration toolset in the Data Management toolbox.

In previous versions, you may have attempted to connect to your enterprise geodatabase, only to receive an invalid or missing ArcGIS Server license error, such as the following:


In ArcGIS 10.4, you can use the new geoprocessing tool that allows you to update your license file, and you can even incorporate the tool into a Python script to automate the process of updating your file, as long as you have a valid license file on hand. You can even schedule the Python script to run at certain intervals using your operating system's scheduling application.

Check out the help documentation on this new tool, and I'll throw in the link to obtain a valid Authorization File tool, just for fun:
Julia L. - Geodata Support Analyst

1 0 2,933
Occasional Contributor II

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.

Let’s review: when a replica is created, the data and schema of the objects being replicated are registered in the parent geodatabase and child geodatabase. The data is defined as the rows in the table and uses the GlobalId values as a link between parent and child, while the schema consists of the fields, domains, subtypes, and other properties that describe the replicated data. Remember, if you use the Distributed Geodatabase toolbar in ArcMap to create the replica, and use the option to 'Register existing data only', then the replica could have differing schemas upon creation. This is allowed as some organizations have a need for this diagram, so it is up to the replica creator to ensure that the data is prepared to their own needs before creating the replica.

Ideally, the schemas are identical on both replicas during replica creation, but over time, changes might be applied to each replica schema. For example, one replica may require additional fields to complete a project, while the relative replica may need to apply a new domain to an existing field. When this happens, the schemas of the replicas are no longer the same. Again, it is not required to have identical schemas in the parent and child geodatabases; however, if the differences are not intended, then you may see some unexpected behavior.

What can happen if there are schema differences in the replicated data?
  • Edits that don't synchronize- Data synchronization only imports changes for tables and fields that are common to both replicas.
    • Note: If schemas do not match when data is synchronized, the data is flagged as having been sent to its relative replica. Remember, replicas do not require schemas to match, but any and all edits will be flagged as synched during synchronization, whether or not there is a matching schema (for example, a field) in the relative replica to receive the edits.
  • Invalid values - Changes that violate domains, subtypes, connectivity rules, and relationship rules are applied when synchronizing changes. The validation tools on the editor can be used to check the newly imported values.
  • Data synchronization errors - This can happen when you manually make a schema change to both replicas. For example, you may want to add a field to a table. If you do this, be sure to make the exact same schema change in all cases. If there is a difference (for example, a field is a string on one replica but an integer in the other), a data synchronization error will occur.

    Synchronization error due to mismatched field types between replicas.

  • Unsupported changes - Some types of schema changes can cause synchronization to fail, but no warning is displayed if you make the change. These changes are not detectable by the geodatabase replication system. They include database-level operations like changing permissions on tables in the database. If permissions are changed to read-only for replicated data, a failure will happen when importing changes from the relative replica.
Applying schema changes across replicas - Modifying the schema of a replica to match the schema of a relative replica is a completely separate process from data synchronization.  If you believe you are encountering some of the unexpected behavior described above, you may use the following tools.

Three tools are provided to update replica schemas:
  1. Export Replica Schema - Used to export the schema from the geodatabase that has the schema you want applied to the relative replica. Typically only used for disconnected environments or scripting.
  2. Compare Replica Schema - Used to find the differences between the two geodatabases in the replica. This is always done from the geodatabase that you want the changes applied to. This is the first step if working in a connected environment.
  3. Import Replica Schema - Used to import the differences found during the replica comparison into the geodatabase that you want the changes applied.

The tools are available on the Distributed Geodatabase right-click context menu in the Catalog tree, Distributed Geodatabase toolbar in ArcMap, and as geoprocessing tools.

Distributed Geodatabase right click context menu in ArcCatalog


Distributed Geodatabase toolbar in ArcMap


Data Management Geoprocessing Tools

It is important to note that there are very slight differences in these three methods. For example, the Import Replica Schema wizard on the Distributed Geodatabase right-click menu from ArcCatalog and the Distributed Geodatabase toolbar in ArcMap list the changes that the user can opt to apply or not apply, while the geoprocessing tools (which are more often used in disconnected environments or scripted automatic processes) do not.

Lastly, keep in mind that the geoprocessing tools are typically used in a three-step process (Export, Compare, and Import) and are mostly used when this process is part of a scheduled task. The Distributed Geodatabase toolbar in ArcMap and the Distributed Geodatabase right-click context menu can be used in a connected environment and with only two steps (Compare and Import).

While eliminating the Export Replica Schema step can save you time, if there is doubt about which geodatabase schema should be the input for the tools, or doubt about which changes are being propagated, I find that the 3-step Geoprocessing Tool method can be much more intuitive. The first tool will always be the Export Schema Changes geoprocessing tool. This tool has only one geodatabase input (the geodatabase that has the schema you would like propagated to the relative replica), and creates a single output XML file.

Now, we run the Compare Replica Schemas geoprocessing tool where our input is the relative geodatabase and the XML file we just created. The output for the Compare Replica Schema Geoprocessing tool is a single XML file. Finally, our third step is to run the Import Replica Schema. Our input will be a geodatabase - the relative to the input we enter in the Export Replica Schema tool, and the compare.XML we just created. While the geoprocessing tools do not have the organized UI that lists the recognized schema differences, this method can clarify any confusion about where the changes are being taken from and where they are being sent to.See Resource documents:
Tina M. - Geodata Support Analyst

1 1 4,855
New Contributor III

Are you running ArcGIS 10.0 for some of your GIS needs? We know, it’s a great platform, but it’s time to move onward and upward. Over the last five years, Esri has developed greater and more powerful functionalities across all platforms, moving from ArcGIS 10.0 all the way to the upcoming release of ArcGIS 10.4. These upgrades have come with more tools, more efficient processing, and more features that allow you to create and share the data and maps you need. If you haven’t upgraded your applications and geodatabases yet, it’s time to start planning. Starting in January 2016, Esri will no longer provide Standard Support for ArcGIS 10.0. Of course, we at Esri Support are more than happy to help with any upgrade questions you may have, and the experience will only be smoother if you don’t wait until the last minute to upgrade. We can walk you through the workflow from start to finish and are here if you run into any issues. The upcoming deprecation of support includes:

  • ArcGIS for Desktop 10.0
  • ArcGIS Server 10.0
  • ArcSDE 10.0 and enterprise geodatabases in version 10.0
  • ArcIMS
  • ArcInfo Workstation 
For more information, check out the following links:Esri Product Life Cycle Support Policy Deprecation Plan for ArcGIS 10.0 and ArcGIS 10.1ArcIMS Product Life Cycle Support StatusArcInfo Workstation Product Life Cycle Status
Julia L. - Geodata Support Analyst

0 0 536
New Contributor III

14676756924_a96569de8b_o-300x199.jpgYou've just updated your client and geodatabases to ArcGIS 10.3, and you want to ensure you are using the most up-to-date ArcSDE command line tools and application server install. So where is the install for ArcSDE 10.3?

For the last several releases, we incorporated more functionality into the user interface of the ArcGIS client. For upgrading the geodatabase repository at 10.0, the Upgrade Geodatabase tool replaced the ArcSDE Post Installation wizard. At 10.1, the Create and Enable Enterprise Geodatabase tools allowed for the deprecation of the ArcSDE Post Installation wizard all together. The application server and command line tools have been an optional install since 10.1, and the database connection dialog box was reworked to allow a direct connect for the default method of working with database connections. Overall, these upgrades prepare us for the deprecation of the command line tools and the application server.

With the release of ArcGIS 10.3 comes the end of support for the ArcSDE service and the application server connections (three-tier). Additionally, ArcSDE command line tools have been replaced by geoprocessing tools in the ArcGIS clients. Therefore...There is no install for ArcSDE 10.3.

You can connect to all of your databases in ArcGIS for Desktop 10.3 using direct connections by adding a database connection in ArcCatalog. You can also use existing SDE files created from application server connections and create application server connections to services from previous versions. Since ArcGIS 10.2.2 is the last release to include the ArcSDE application server, we encourage you to use direct connections moving forward.

If you're wondering what to do about the ArcSDE command line tools no longer being available, geoprocessing tools have been added to the Geodatabase Administration toolset to help you with any administrative needs. So rejoice! There is one less step in the installation process of upgrading to the newest versions of ArcGIS products.

Please follow the GeoNet discussion for more in-depth conversations related to the install for ArcSDE 10.3.

For additional information, check out our documentation linked below:ArcGIS for Desktop Help: What's new for Geodatabases in ArcGIS 10.3?ArcGIS for Desktop Help: Client and Geodatabase Compatibility in 10.3ArcGIS for Desktop Help: Database servers in 10.3ArcGIS for Desktop Help: Database connections in ArcGIS for DesktopArcGIS for Desktop Help: Migrate from ArcSDE administration commands

Julia L. - Geodata Support Analyst

1 1 10.2K
Esri Contributor

Please be aware that if the recent Oracle Critical Patch Update (CPU) released on October 14th, 2014 is installed on your Oracle database, connecting to the Oracle database will crash ArcGIS.

This issue only affects you if you use Oracle. All versions of ArcGIS are impacted by this CPU.What You Need to Do:

  • If you have not yet installed the patch listed above, do not install it, per Esri's recommendation.
  • If you have installed the patch listed above, Esri recommends that you roll it back to restore normal operations.

Esri and Oracle are working closely to understand and resolve the problem.For specific details, see Esri Knowledge Base article 43293.

0 0 2,761
Esri Contributor

In my line of work, I must have at least a working knowledge of each database management system (DBMS) supported by Esri. Other vendors require near-perfect database administrator (DBA) expertise. This means I am constantly looking at error messages.

Some I have memorized, but there is no way I will ever be able retain all of them in my memory. So, here are some resources I use for looking up the meaning of those vague return codes. What are yours?

I also found this query for SQL Server very useful.
SELECT message_id, severity, text
  FROM sys.messages 
  WHERE language_id = 1033;

Ken G. - Geodata Support Analyst

0 0 569
by Anonymous User
Not applicable

You’re all set to take on a Workflow Manager database as the new administrator. All is going well, until you try to log in to Workflow Manager Administrator. At that time, you get the following error, “Current user is not an administrator on the selected database. Please contact your administrator.” (Figure 1)


Figure 1 - Not an Administrator

When I first experienced this, my natural instinct was to follow my nose down the trail that the error had provided. Like me, you may even decide to grant database administrative rights to the user in question in an effort to temporarily alleviate this error. Unfortunately, this is technically not the case and you will continue receiving this error.

Don’t worry - it’s not your fault. This error is technically correct, but tends to be misleading. It gives the impression that the database user needs additional administrator privileges. This is not the case.

As it turns out, the error is not with the database user, but with the Workflow Administrator user which is stored on the Workflow Manager database. First, each user registered with the Workflow Manager database is listed as either having or not having administrator access. Second, each Workflow Manager user is associated with a Windows user (Figure 2).

Figure 2 - User Properties

When you open the Workflow Manager Administrator application, the problem surfaces because it is using your Windows credentials. If your credentials are not associated with a Workflow Manager user, the error will be flagged. Or, if those credentials are associated with a Workflow Manager user, but the user lacks administrative rights, the error will also be flagged.Solution

You need to find the user which exists on the Workflow Manager as an administrator, access the application as that user, then add your own user as an administrator. This is how to do it:
  1. Access your DBMS software.
  2. Access the Workflow Manager database. If you’re not aware of which database you’re looking for, right-click the connection of interest in ArcGIS Workflow Manager Administrator and select Properties. (NOTE: This is not to be confused with User Properties!)
  3. View the JTX_USERS table.
  4. Find the IS_ADMIN column.
  5. Locate any record in the IS_ADMIN column which is assigned a value of -1.
  6. Take note of the value which is in the USERNAME column that is associated with the record found in Step 5 (Figure 3).

    Figure 3 - USERNAME/IS_ADMIN

  7. Ensure that your Windows environment contains a user identified by the value found in Step 6.
    • If the Windows environment does not contain a user identified by the value found in Step 6, create a user.
  8. Open the Workflow Manager Administrator application as the user identified or created in Step 6. (This can be achieved by holding down the Shift key and right-clicking the Workflow Manager Administrator application and selecting 'Run as Different User'. Alternatively, you can log out and then log in to the machine as the user found in step six.)
  9. Connect to the environment.
  10. Now you’re in. The best thing to do here is to add your normal login as an administrative user to the Workflow Manager environment within the Security/Users section.

Congratulations! You’ve changed the existing environment into acknowledging you as an administrative user. As a result, the administrator error is gone, and you’re ready to administer some workflows!

0 0 2,635
Occasional Contributor III

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 tools in ArcCatalog/ArcMap that will make transitioning as seamless as possible.

If you are a frequent visitor of the ArcSDE Administration Command reference you may have noticed within the latest versions of the command line reference, there are numerous areas that include a little globe to indicate alternate or recommended workflows:globe.jpg

NOTE: There are no web-based versions of the ArcSDE command line reference for 10.1 and 10.2, but it can still be accessed on the server on which the application server/command line tools are installed.

In order to put a nice spin on delivery I will use a ‘Do This, Not That’ theme with a list of tasks within the Enterprise geodatabase that have alternate solutions or tools. I have also thrown in a few tasks that may not be directly related to the command line, but which have new recommended workflows.

Create an Enterprise geodatabase:

Use the Create/Enable Enterprise Geodatabase tool instead of using the ArcSDE Post Installation Wizard

This may seem like a no-brainer since the ArcSDE Post Installation Wizard was deprecated at the 10.1 release, but I thought this would point you in the right direction (or at least humor you).

Recalculate the layer extent:

Use the Feature extent tab within the layer properties of ArcCatalog instead of the sdelayer -o alter -E calc command line tool.

Recalculating the XY extent can now be done within ArcCatalog using the Feature Extent tab of the Layer Properties. This tab was added at release 10.1 for the ability to administer the XY extent of layers.

Create a multi-versioned/versioned view:

Register as versioned instead of using the sdetable -o create_mv_view command line tool.

Note that the terminology for multi-versioned views has transitioned to versioned views at the 10.1 release and how they are created has changed. Registering data as versioned starting at version 10.1 will automatically create a versioned view.

What if your data is already versioned and doesn’t have a versioned view created?
    • At version 10.1, the Create Versioned View tool can be used if the data was already versioned prior to upgrading and doesn’t currently have a versioned view created.
    • At version 10.2, the Create Versioned View tool is removed. Use the ‘Enable SQL Access’ context menu for these instances where the object does not have a versioned view.

For more details on using the Enable SQL Access context menu, review the Help topic, Enabling SQL access on geodatabase data from ArcGIS for Desktop – 10.2

Place a layer in load only or normal IO mode to bulk load data or rebuild the spatial index:

Use the Layer Properties Index tab, or the Remove/Add Spatial Index geoprocessing tool instead of the sdelayer –o load_only_io/ normal_io commands.

Starting at version 10.0 the Add / Remove Spatial Index (Data Management) geoprocessing tools are available.

View the spatial column of a table that is not registered with SDE or the geodatabase:

View in Database Connections in ArcCatalog or drag/drop into ArcMap as a query layer (feature discovery) instead of using sdelayer -o register

In previous releases, database tables that contained spatial types needed to be registered with ArcSDE for their spatial column to be accessible. This resulted in the table displaying as a feature class after registration. At version 10.1, tables that contain geometry types such as Oracle Spatial and SQL Server Geometry are accessible through ‘Database Connections’. These tables will be displayed with a table icon with a square. Double-clicking will connect and determine/discover the geometry type and the icon will change to a feature class representing the geometry type.db-connections-icons.jpg

If needing to take advantage of geodatabase functionality, you can register the feature classes/tables with the geodatabase, which will also registers them with the ArcSDE system tables during the process.

Managing connections:

The Geodatabase Administration tool is new at 10.1 and can be accessed by right clicking on the geodatabase > Administration > Administer Geodatabase context menu item. One of the many uses for this tool is that it provides a user interface to view and interact with user connections. Keep in mind that certain permissions must be granted to view/disconnect users. Consult the Help topics for more details on this.Viewing connected users in ArcGIS for Desktop – 10.2Removing connections from a geodatabase in SQL Server – 10.2Removing connections from a geodatabase in Oracle – 10.2Removing connections from a geodatabase in DB2 – 10.2Removing connections from a geodatabase in PostgreSQL – 10.2A quick tour of administering ArcSDE geodatabases with ArcGIS for Desktop – 10.2

  • View currently connected users for geodatabase / view locks:

Use the Connections and Locks tab within the Geodatabase Administration tool instead of using sdemon –o info –I users/locks
  • Prevent new connections to the geodatabase:

Prevent new connections to the geodatabase in geodatabase Properties > Connections tab instead of using sdemon -o pause/resume
  • Disconnect users from the geodatabase:

Use Geodatabase Administration tool > Connections tab > Disconnect instead of sdemon -o kill

Importing datasets to the Enterprise geodatabase – shapefiles and coverages:

Use the Feature Class to Feature Class (conversion) geoprocessing tool instead of shp2sde –o create command line tool.

This geoprocessing conversion tool can be run in batch mode or scripted in ArcPy to import shapefiles into the geodatabase. If there is a further need to adjust the field mapping within the tool, use the arcpy.FieldMappings class.

We are continually working on alternative user interface solutions to the command line tools. Please contact Esri Support Services if you have workflows that use the command line tools and are unaware of alternative workflows you can utilize from the user interface.

For on-going discussion related to this topic, please visit the ArcGIS Forums: Alternatives to using SDE command line tools - Blog DiscussionMelissa J. - Geodata Support Analyst

1 0 4,559
Esri Contributor

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.

The scripts found in Esri Knowledge Base Article 24518 provide the SQL to both update statistics and rebuild indexes.


  • Oracle databases can be set to automatically update statistics.
  • The SQL Server script in KB24518 is still applicable for geodatabases in SQL Server 2008, 2008R2 and 2012.

Also, if you are using ArcGIS 10.2 or 10.1, there are some new geoprocessing tools in the ArcToolbox that can accomplish this:Data Management Tools > Geodatabase Administration > Analyze Datasets:
Updates the database statistics of base tables, delta tables, and archive tables, along with the statistics on those tables’ indexes. This tool is used in enterprise geodatabases to help get optimal performance from the RDBMS query optimizer. Stale statistics can lead to poor geodatabase performance.Data Management Tools > Geodatabase Administration > Rebuild Indexes:
Updates indexes of datasets and system tables stored in an enterprise geodatabase. This tool is used in enterprise geodatabases to rebuild existing attribute or spatial indexes. Out-of-date indexes can lead to poor geodatabase performance.

No matter which one you choose, these resources can be run as automated tasks using SQL, or the ArcToolBox tools can be exported to Python and automated as well.Ken G. - Geodata Support Analyst

0 0 1,779
41 Subscribers