conwaylw

Some users crash ArcMap 10.4 selecting records from SQL Server

Discussion created by conwaylw on Aug 24, 2016
Latest reply on Apr 25, 2017 by ndei-esristaff

Greetings,

We have been dealing with crashes for some users since we upgraded to 10.4 (and 10.4.1). After some research, a bug was submitted by Support Services that found that usernames over 22 characters crash ArcGIS Desktop 10.4.x when selecting over 100 records from a SQL Server 2014-based enterprise geodatabase configured with session-based log files.

 

 

Here is our setup:

 

DBMS: SQL Server 2014
Access Control: Windows Groups
Client: ArcGIS Desktop 10.4/10.4.1

 

 

Findings:

 

There were some users that were crashing ArcMap 10.4.x while selecting records and other users who were not having any problems. We tried re-installing ArcGIS Desktop 10.4, provisioning brand-new Windows 7 & 10 desktops, and running ArcGIS Desktop 10.4.x on server operating systems. We also looked at SQL Server-based permissions, Active Directory user attributes, and ODBC vs. Native SQL Server clients. All pointed to something wrong with a user account and the only thing that was different was the length of the user name.  According to documentation here, a log table is created in TEMPDB when a client user selects more than 100 records using the default session-based log file configuration. Even when granted access via a Windows group, the logging operation uses the fully-qualified username.  Our Windows domain name alone is 13 characters. When paired with a username that exceeds 8 characters (DOMAIN[13] + "\"(1) + USERNAME[8]) ArcMap 10.4.x crashes when performing a selection of over 100 records. In testing, we created a long SQL Server login (non-Windows) username and got the same result.

 

 

Exclusions:

- 10.3.1 desktop clients are unaffected; only 10.4.x.
- Users who are DBO in the database don't experience this problem.

 

 

Unknowns:

- We did not test ArcGIS Pro.
- The web GIS seems OK but we haven't messed with it.
- We don't know if this affects SQL Server 2012 as we don't have any enterprise geodatabases running on it.

 

Workaround:

Until ESRI can address this issue, the workaround is to switch from session-based log files to either shared log files or log file pools.

 

We hope ESRI will fix this bug soon, but we wanted to post it here to see if anyone has experienced this super-frustrating issue.

 

Thanks,

 

Levin Conway

Outcomes