Slow editing in 10.1

14006
40
06-22-2012 06:47 AM
RobbHodges
Occasional Contributor III
I've been having issues when editing a version 10 geodatabase in ArcGIS 10.1 from the network. Editing a version 9.3 seems to be fine. With ArcGIS 10, I was having zero issues editing from the network. Basically, selecting anything has a noticeable delay. Moving anything results in at least a 10 second delay. Editing the same data on my local results in zero problems.

I called tech support and they initially blamed it on the network. Well, 2 days prior, it worked fine on the same network. There were no changes made to the network, only to the upgrade of version 10 to 10.1. We then tried renaming the normal.mxt and the esri folders in the registry. That didn't work either.

Has anyone experienced this in 10.1? It's a bit frustrating, because we really need this to work from the network. I am editing on my local right now as a temp fix, but eventually that won't work.

Thanks,
Robb
Tags (2)
0 Kudos
40 Replies
MichelleBoivin
Occasional Contributor
Out of curiosity, has anyone on this thread tested or upgraded to 10.2 and attempted any of the above? Is 10.2 having the slow editing issue (or any other major issues for that matter)?
0 Kudos
RobbHodges
Occasional Contributor III
In our case, it was a matter of our server. We were storing all of our GIS data on an older linux based server. We've since moved everything over to a newer windows based server and have seen speed dramatically increase (not just in GIS, but across the board).
0 Kudos
ClintRichmond
New Contributor
I have spent several weeks working on our slow editing situation.  We are on 10.1 with direct connection to SQL Server 2008 R2 on a VM.  I discovered that our issue involved database authentication.  When I switched over to operating system authentication, editing became lightning fast.
0 Kudos
MichelleBoivin
Occasional Contributor
I've been having issues when editing a version 10 geodatabase in ArcGIS 10.1 from the network. Editing a version 9.3 seems to be fine. With ArcGIS 10, I was having zero issues editing from the network. Basically, selecting anything has a noticeable delay. Moving anything results in at least a 10 second delay. Editing the same data on my local results in zero problems.

I called tech support and they initially blamed it on the network. Well, 2 days prior, it worked fine on the same network. There were no changes made to the network, only to the upgrade of version 10 to 10.1. We then tried renaming the normal.mxt and the esri folders in the registry. That didn't work either.

Has anyone experienced this in 10.1? It's a bit frustrating, because we really need this to work from the network. I am editing on my local right now as a temp fix, but eventually that won't work.

Thanks,
Robb


Robb et al, 😮

We just finished running some additional tests on our side per ESRI's request (we had our PM from ESRI on the phone looking at exactly what was happening - sluggishness, etc.) They suggested setting up a separate database on the same box (in our case Production), and changing the data storage back to SDEBINARY rather than GEOMETRY (ESRI's default). Once we did and tested while editing with numerous users for 1.5 hours, we saw an improvement. I then went back to our Production data, backed up the new geometric networks, recreated them, and then imported the data using the SDEBINARY config keyword. When I came in this morning, PERFMON (or the performance on the server and on Desktop) have vastly improved to where I am actually happy and satisfied with the outcome. We are still continuing to review the situation and make sure it stays this way.

We did not have to change the data types for all of the data in the Production database, but just the networks that were giving us the problem, so we can still have the SQL Server functionality for 98% of our data in the database. It appears that ESRI has not yet caught up to the SQL Server storage types with their more advanced networks or data types.

Hopefully this will help some of you as I know it has been VERY trying here, but as I mentioned, we have noticed a significant difference in our data and our editing.

Cheers,
Michelle
0 Kudos
MichelleBoivin
Occasional Contributor
As we are continuing to work on some issues mentioned above, ESRI has emailed us the following regarding performance issues when using SQL_Geometry:

http://support.esri.com/cn/knowledgebase/techarticles/detail/38871 (Our (ESRI's) kb article on bug)
   -discusses issues on a multiproecssor system and a bug in MS' query optimizer. Their fix is in SP2 - only problem is we are    already on SP2......
http://support.microsoft.com/kb/2570501 (MS kb article on bug)
   -speaks to the parallel query against a large spatial table
http://support.microsoft.com/kb/2591748 (specifically mentioned in this fix)

Suggest having a DBA take a look and run a trace to document the issues.

~Michelle
0 Kudos
jennifergordon
New Contributor II
Ever since we've gone to 10.1 with the direct connect we've had nothing but problems. We've had multiple duplicate key errors and countless snapping issues. The snapping will just at times quit working all together, but strangest we've encountered is snapping issues with a large lake layer. It's located on the SDE and anytime a person goes to edit it the snapping gets killed until a compression is done. I would get it if we did a lot of edits, but all it takes is moving one point in this file and snapping dies for every other layer until a compression is done. We have very few people that look at the layers on the SDE and only two edit on it but we need it to work. Before we upgraded from 10 to 10.1 it worked fine. We have moved several points but haven't really added many so the file size hasn't changed much from then to now.
0 Kudos
FreekBusschers
New Contributor
Dear all, we're (and 20 of my collegues) also experiencing dramatic editing sessions. Adding or moving a node takes ages. This was not the case in 9.3. We've reached the point of ''not workable anymore''. Can anyone tell me what's the latest conclusion on this topic? Is it a network configuration that we have to change or something else? Is shape caching not a solution?

Cheers, Freek, the Netherlands
0 Kudos
BillLotz
Occasional Contributor II
Same problem here. Editing features over network in a SQL 2008 R2 database, and ESRI 10.2. Direct connect OS authentication. Can turn of snapping and it still hangs. Editor can be editing fine, but then selects a line and it just spins for a minute, then finally selects.
0 Kudos
MichelleBoivin
Occasional Contributor
knoxgis & fsbusschers, if you have a test environment or some movement in your Production environment, 1) make all layers binary rather than geometry that participate in the geometric network 2) rebuild the networks, 3) begin editing. We saw a drastic improvement in editing with the geometry change. This was also confirmed by the ESRI consultant that was out here working with us. In addition, make sure no one is editing default (we never think folks are, but some do). That weighed in on the editing lag as well. However, the change in spatial storage type was the largest difference of all.

~Michelle
0 Kudos
MichelleBoivin
Occasional Contributor
Also, something else they mentioned was installing SP2 for SQL2008R2 which included a MX hotfix for spatial indexing in SQL and then setting the traceflag to 4199. This also worked for us. It is included with SP2, else you have to install the Hotfix separately for previous versions. Below is the traceflag URL http://support.microsoft.com/kb/974006. In addition, here is the URL for the Microsoft Hot Fix (2008R2) http://support.microsoft.com/kb/2570501.

Please feel free to email me separately for any questions. We have exhausted a lot of time trying to get to the bottom of this issue and have finally gotten to where we can function properly, although not optimally.

Cheers,
Michelle
0 Kudos