Latest Contributions by ShannonShields

Short answer: it won't matter in this case what you set it to. It is very, very rare that something in ArcGIS would hinge on the database compatibility level. However, technically speaking ArcMap is not supported with SQL Server 2022 (regardless of the compatibility level). We won't prevent you from connecting, but it is an unsupported configuration. Longer, more detailed explanation of compat levels: The SQL Server compatibility level is a property of the database that basically controls which SQL Server features or TSQL syntax is available. It is really there so that older SQL Server applications, that may use deprecated features or syntax, can connect to databases on newer versions of SQL Server. For example, many years ago the where clause join syntax was deprecated in favor of ANSI join syntax. At a specific release that syntax was no longer available and could not be used....unless the database compatibility level was set to an earlier version before that syntax disappeared.  The compatibility level is not automatically increased on existing databases when you upgrade SQL Server unless the compat level is earlier than SQL Server 2017 (I think 100). It is an explicit choice that the DBA makes, based on what applications are currently interacting with that database, and do they need older things that may not be present in a new database. The opposite can also be true - there may be new features tied to a new compatibility level that you'd like to take advantage of. Often Microsoft will introduce a new optimization behind a trace flag, and in a later release it will no longer require a trace flag, but the compatibility level will need to be increased. The compatibility level isn't the same as the release of SQL Server where the database is hosted. If you have SQL Server 2022, and new databases you create will automatically have the 2022 compatiblity level (170), but existing databases won't get upgraded. However, everything on that instance will be a 2022 database. Version and compatibility levels are not the same thing. https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-database-transact-sql-compatibility-level?view=sql-server-ver17 ... View more

There is currently various levels of support for connecting to SQL Server in an Azure environment - SQL Server on an Azure VM, Azure SQL Database, Azure Managed Instances. Is this specific to any of these flavors, or is this specific to Azure Synapse. Please change the title and description to be more specific. ... View more

You would need a function like ST_Transform, which unfortunately Microsoft does not provide for its Geometry data type. You won't be able to do this at the sql level. ... View more

The backup & restore tools provided by each supported DBMS platform are the preferred way to backup and restore enterprise geodatabases. An Enterprise geodatabase should be backed up according to the recovery point objectives of your organization by using the tools provided by the DBMS vendor. ... View more

Support for a Hibernate Dialect for enterprise geodatabases is not in the product plan. ... View more

There have been several new features in the 15 years since this idea was first raised that extend geodatabase functionality to either support or provide equivalency to additional dbms functionality:  query layers, support for database views, contingent values, attribute rules, sequences etc. This idea is somewhat vague in terms of which dbms components to support, and in what capacity.  ... View more

Support for column-level permissions in enterprise geodatabases is not in the product plan.  ... View more

This idea has been closed due to inactivity. ... View more

Support for a geodatabase in MySQL is not in the product plan. ... View more

ArcGIS Desktop is no longer under active development. If similar functionality is required for ArcGIS Pro, please submit a new idea. ... View more

ArcGIS Desktop is no longer under active development. If similar functionality is required for ArcGIS Pro, please submit a new idea. ... View more

When data is not versioned, and not archived it is possible to support individual insert or update or delete permissions for edits made directly from ArcGIS Pro. However, when the data is archived or registered for versioned editing the model does not support individual permissions. While it may appear that edit operations are inserts, updates, or deletes the model used by ArcGIS may not translate to the same DBMS-level operations. For example updates and deletes to versioned data are actually inserts at the database level. For a user to successfully edit using traditional or branch versioning, or non-versioned archiving, all permissions must be present. For edits made via feature services, it is the service publisher that is actually executing the edit in the database, rather than the portal user who is performing the edits.  ... View more

Feature datasets are specific to storing spatial data that participates in a controller dataset. Non-spatial tables are not part controller datasets and therefore will not be part of feature datasets. For more information on feature datasets and their intended use please see https://pro.arcgis.com/en/pro-app/latest/help/data/feature-datasets/feature-datasets-in-arcgis-pro.htm. ... View more

We do not have any plans to modify the ArcGIS data model to support multiple entity types in a single feature class. ... View more

This is functionality that is already available to a DBA. There are many tools available to perform security audits at the database level. ... View more