Latest Contributions by ShannonShields

Given that you are also getting a login error using sqlcmd, this isn't an ArcGIS problem. When you restored this database was it to a new/different instance of SQL Server? Did you re-create the login and link it to the user in the restored database? If you are using a database login (e.g. not Windows login) then you'll need to re-link it to the database user using the ALTER USER <username> WITH LOGIN = <loginname> command. ... View more

Like I said earlier, there is nothing in ArcGIS that is dependent on the compatibility level of the database. You can change it to 170, or leave it at 130 (2016). It is not the same as the version of SQL Server where the database is actually hosted. I'd recommend updating it if you do not have a reason not to (e.g. another older client application that relies on older, deprecated functionality) but that is more my opinion than any requirement of ArcGIS software. We do not typically prevent an older client (like ArcMap) from connecting to a newer geodatabase, or newer version of SQL Server, but we do require that the database version (not the compatibility level of the database, but the version of SQL Server) be compatible with all the pieces - the version of ArcGIS Server, the version of Pro, the version of the geodatabase. This KB article gets updated at each release with the versions of SQL Server that are supported by each release. https://support.esri.com/en-us/knowledge-base/is-my-sql-server-database-version-supported-by-arcgis-e-000030039. Upgrading your geodatabase will only be possible if the database version is supported by the version you are trying to upgrade to. We will block upgrade on an unsupported version. For ODBC 18, ArcGIS Desktop will require patching in order to use it - if you are running 10.8.1 the patch is https://support.esri.com/en-us/patches-updates/2024/arcgis-desktop-10-8-1-general-component-updates-patch, and if you are running 10.8.2 it is https://support.esri.com/en-us/patches-updates/2024/arcgis-desktop-engine-10-8-2-general-component-updates-patch-2 And lastly, we have always announced deprecation of a SQL Server version shortly after it ages out of Microsoft's Mainstream Support (5 years). This means that you usually have ~6 years with a version of SQL Server before we no longer support it with our current releases. If you choose to upgrade ArcGIS software frequently, then you will also need to plan for more frequent upgrades for SQL Server. PostgreSQL reaches end of life every 5 years so has a significantly shorter lifespan.  -Shannon ... View more

Can you please give an example of the workflow you wish to have. E.g. are you looking for the ability to execute full-text search via Select by Attribute? In a definition query?  ... View more

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