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:
Have you ever attempted to run a geoprocessing tool, only to have the tool fail? Perhaps your data fails to publish to ArcGIS Online or draws incorrectly on your map. Maybe you are running a geoprocessing tool only to have it fail with a generic error message. You are using the same workflow you use every day with the same settings and configuration, but you can't seem to find another cause to the problem.
You may be dealing with a data-specific issue. There are a few basic troubleshooting steps that may provide a resolution to this, but it all starts with determining if the issue is truly data-specific. Determining if an Issue Is Data-specific
A quick test to determine if an issue is data-specific is to bring your dataset into a blank map document, map frame, or web map (depending on the environment in which you are working). If the issue does not persist in a new map, then the issue may be specific to the map document. If you experience the same issue in a new map document, the source of the problem may be the data.
Another way to determine if an issue is data-specific is to run the same process with a different dataset similar to the one that you are using. For instance, if using a point shapefile that fails to import into your file geodatabase, run the process on a different point shapefile of a similar size. If the tool or process succeeds on the new dataset, then the issue may be data-specific. Luckily, there are tools available that can help to resolve some of these data-specific issues.
If you find that the problem or error is reproducible with multiple datasets, you may want to investigate some of our additional resources to determine the source of the issue. Feel free to check out more resources from the first post in the WWTSD series (linked above).Possible Data-specific Issues and Their Solutions
A geometry error can be one potential source of a data-specific issue that has a quick fix. ArcGIS applications require that a feature's geometry meets certain standards. Issues can occur if any features have null or incorrect geometry. In ArcMap and ArcGIS Pro, you can determine if your dataset has any geometry errors by running the Check Geometry tool, which generates a table that lists the geometry errors found in the data. If there are errors present in the resulting table, run the Repair Geometry tool to fix the geometry errors present in the data. It is recommended to make a copy of your data prior to running this tool, as the tool may delete records with geometry errors.
If your features appear in a different location on the globe than you would expect, your data may have an issue with your data's projection. You can view the coordinate system of your data by navigating to the properties of the layer. If the data does not have a defined projection, you may need to use the Define Projection tool to assign the correct projection (see the tool documentation here for more information). If your data has been assigned a different projection than the other layers in your map, you may need to use the Project tool (here) to alter the coordinate system of your data. For more information about when to use the Define Projection tool versus the Project tool, take a look at the blog post found here. If you do not know what projection your data should be in, please see the technical article here for more information.
Data can become corrupt for various reasons, including incorrectly copying data or experiencing connection issues to a network drive. These issues sometimes can be resolved by exporting the data into a different format or location, such as to a different feature class or to a .tif rather than to a .png raster file. If you are working in a file geodatabase, run the Recover File Geodatabase tool, which creates a new file geodatabase with repaired versions of feature classes that the tool identifies as potentially corrupt. Considerations for Raster Datasets
Raster datasets have many parameters and properties and therefore, many sources of data-specific issues. The following by no means addresses all potential issues with raster datasets, but does address a couple common sources of data-specific issues for rasters and troubleshooting steps to address the issues.
Bit-depth is a characteristic of a raster that defines the possible cell values allowed for the dataset (for more information, click here). If the bit-depths of two or more rasters that you are running a geoprocessing operation on do not match, you may run into errors or issues. For instance, if you create a mosaic dataset containing rasters from multiple sources, you may want to confirm that the bit-depths of the rasters are the same. You can determine the bit-depth of a raster by navigating to the raster properties. If you must change the bit-depth of your raster, you can use the Copy Raster tool to manually set the necessary bit-depth and create a new output raster with those parameters.
When adding a raster dataset to a map document or creating a new one, you are given the option to build pyramids that control how the dataset is viewed at different scale levels. If you are unable to view your raster dataset at some scale levels, but not at other levels, the raster pyramids may have become corrupt. Exporting the raster into a different format or deleting and rebuilding pyramids may help resolve this issue. If you would like more information about deleting and rebuilding pyramids, click here.Contact Esri Support
These steps can help to begin narrowing down potential causes to an issue, but they may not resolve every potential problem. If you need additional assistance with diagnosing or resolving an issue, feel free to contact Esri Support. We are happy to assist our customers resolve any technical issue they encounter. When contacting Esri Support, please be prepared to provide the following information so that an analyst can assist you as efficiently as possible.
This blog post provides the latest updates regarding deprecated features in ArcGIS 10.4 and in the recent release of ArcGIS 10.4.1.
With each release, the platforms and functionality supported in the ArcGIS platform are assessed and adjusted based on customer needs and technology trends. The purpose of the Deprecated Features for ArcGIS document is to provide as much advanced notice as possible regarding these changes.
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:
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.
Two important things are needed to get a full compress on a geodatabase that still has replicas registered.
The existing replicas must be the data sender in the replica relationship.
Every replica version must be at the same state as DEFAULT version.
This means that for Two-way replicas, there can be no SYNC_RECEIVE or SYNC_RECEIVE_REC versions in the geodatabase that need to be compressed.
The example below shows the parent geodatabase versions table. All versions associated with a single replica will contain a synchronization version id number in the version names. There are two replicas in this versions table. The One way replica, represented by the synchronization version ID number 10554, is a parent to child replica. Notice the DEFAULT state_id is 398, while this synchronization version is only at state_id 395. One-way replicas will only contain an associated replica version in the data sending geodatabase.
Going on, the replica with synchronization version 10552 is a two-way replica. Two-way replicas can be more complicated since the edits may travel in either direction, frequently switching the data sender and receiver roles. Notice that this two-way replica does have the SYNC_RECEIVE and SYNC_RECEIVE_REC versions associated with it, meaning that this version is in the data receiver role.
This example is making the assumption that there are no named child versions, and that connected synchronization is being used.
To prepare this geodatabase for a full compress, I must do the following.
Synchronize the one-way replica.
Synchronize the two-way replica, sending changes from this geodatabase to its partner geodatabase. The image above shows the versions table in the parent geodatabase, and tells me that this parent is currently set as the data receiver; therefore, I will synchronize parent to child, in effect making this geodatabase the data sender.
The results of these two steps are shown in the image below.
With all of my versions set as acknowledged data senders and with the state_id equal to the DEFAULT version, my geodatabase is ready for a full compress.
Note that it is common to see these two requirements met, and yet only get a partial compress. If this is the case, synchronize the replicas in the geodatabase that need a full compress again. Even though no changes are being sent, acknowledgements are being sent that will tell the geodatabase that the edits are recognized and can be flushed from the delta tables.
In general, look to achieve some level of compress rather than a full compress. Attempting to achieve a full compress may lead to many additional synchronizations which may not be practical in your particular business workflow.Tina M. - Geodata Support Analyst
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?
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 geodatabase-aware, without having to go through the process of registering the objects with ArcSDE or the geodatabase.
When first released, the only way to create a query layer was in ArcMap using the Add Query Layer tool, which also required a special connection file (.qcf). This file was required for ArcGIS to connect to databases that did not have a geodatabase component. Native access to both spatial and non-spatial database objects through the ArcGIS client application allowed for the ability to integrate a wider spectrum of data into GIS projects, and provided the ability for modification to include a specific subset of data – similar to a definition query and/or a database view.
With the ArcGIS 10.1 release, new functionality was added to make database connections native in ArcGIS, which eliminated the need to create the query connection file (.qcf) when building query layers. Query layers evolved from something that could only be manually built to a behavior that automatically occurs when accessing database objects that are not geodatabase-aware through a database connection file (.sde) in ArcGIS. In other words, query layers are generated dynamically by adding non-geodatabase objects to ArcMap via drag and drop from the Catalog window.What is a query layer?
Are query layers read-only?
Query layers are read only in ArcMap. At the 10.1 release, ArcGIS Spatial Data Server (SDS) services were introduced, which allowed the publishing of database data in an editable feature service. At 10.2, ArcGIS for Server feature access enabled map services were enhanced to allow data to be published from database connections that didn’t contain the geodatabase system tables. This opened up the ability to edit query layers via an ArcGIS for Server feature service and eliminated the need for the ArcGIS Spatial Data Server (SDS).Ability to edit query layers:
NOTE: To publish editable feature services via SDS, ensure the layer is not contained within a geodatabase.
Beginning with ArcGIS 10.2, you should use ArcGIS for Server feature services to publish data from supported database management systems. This allows you to edit query layers via the feature access enabled map services, and takes the place of ArcGIS Spatial Data Server feature services (which have been deprecated). These workflows are intended for databases that do not have the geodatabase system repository tables populated; I like to call these NON-geodatabases.
NOTE: When authoring feature services using enterprise or workgroup geodatabases, all data must be registered with the geodatabase. This means that if you have query layers or spatial tables contained within a geodatabase that are not registed with the geodatabase, you will experience errors in analyzing when preparing to publish. Your options are:
Register the spatial tables or query layers within the existing geodatabase, creating feature classes
Publish the feature service from a NON-geodatabase (a database that is not enabled with the system repository tables)
Publish query layers from a map service and overlay these with feature service layers in a web map
A query layer can be created manually in ArcMap by building a query against objects that exist within a geodatabase or a database that does not contain the geodatabase system repository tables. You should use this method to create a query layer if you need to define a subset of data. For example, when working with a layer that contains a large number of features, you should use the Add Query Layer tool and include a 'where' clause that restricts the number of features that will be included in the query layer.
Build a Query Layer manually using the ‘New Query Layer’ dialog in ArcMap: File > Add Data > Add Query Layer
A query layer is created when the layer/table that is not registered with the geodatabase is added to ArcMap via these additional methods:
Starting at 10.1 - Drag and drop a database layer into ArcMap from ArcCatalog or the Catalog window in ArcMap –The ArcMap Layer properties will display a Data Type of ‘Query Feature Class’ within the source tab
Using the Add Data button within ArcMap to add data from a database
ArcGIS for Desktop reads the layers in a database that contain feature geometry and displays them within ArcCatalog. How these appear in the Catalog tree changed starting at the 10.1 release. When data is viewed in ArcCatalog or the Catalog window in ArcMap, a new icon is displayed. This icon indicates that the object is a non-geodatabase aware/registered table with a spatial component/column.
Dragging a database layer with this icon into ArcMap would create a query layer where the feature geometry is discovered and rendered.
Double-clicking this object within ArcCatalog will discover and change the icon to a feature class icon for the specific geometry type that is stored in the geometry column.
Within ArcMap the layer will display similarly to a feature class, but checking the layer properties source within ArcMap reveals the Data Type of Query Feature Class.
Important things to note about query layers: - Query layers only persist within the map document that they were created in - Query layers do not require a geodatabase - Query layers are read-only in ArcMap when added directly from a database connection - Currently, query layers are only editable when accessed via certain types of services and datasources:
10.1 – Spatial Data Server feature access enabled services can edit query layers
This functionality only existed for one product release as it was incorporated into the feature access enabled map service at the 10.2 release
10.2 – Query layers can be edited as part of a feature enabled map service published from databases (not enabled with the geodatabase system repository tables)
- .qcf files are query connection files that were generated for the 10.0 release to allow the connection to a non-geodatabase-aware relational database to build a query layer. Starting at the 10.1 release these were no longer needed, but continued to work.