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:
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:
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. Thevalidation 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:
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.
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.
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:
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
You'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.
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?
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:
Access your DBMS software.
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!)
View the JTX_USERS table.
Find the IS_ADMIN column.
Locate any record in the IS_ADMIN column which is assigned a value of -1.
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
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.
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.)
Connect to the environment.
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!
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:
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
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.
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.
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.
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.
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.
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