nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Slow editing in 10.1

RobbHodges

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

Find more posts tagged with

Accepted answers

All comments

JohnFell

Aaron,

How is editing going at SQL2014? Are you at SP1? Our organization is looking at moving to this soon.

Aaron_Kreag

Just to wake up this thread...we are using 10.2.2, SQL2012 SP2 and SDE with DBO schema and direct connect. We have been fighting this issue for almost one year with no resolution. The SDE Geometry type seems to be a culprit and yes we heard SDEbinary was going away at 10.4. It seems worse when the data is within a feature data set. We are still testing different variations. I have recently set up a test environment with 10.3.1 and SQL2014. If anyone has more info, please drop a note. Thanks!

JonathanMori1

Hmm, that's not good. Did they mention that SDEBinary was going away in 10.3? We are using 10.2.2. SDEBinary seemed to be our best solution to the performance problems we were having. It may be a while until I update to 10.3 if this is the case.

TONIFAIRBANKS

We migrated to SDEGeometry because it is ESRI's standard and we were informed that SDEBinary was going away. We continue to have performance problems and are working with ESRI to try and resolve the problems, but we still don't have a clear path forward. We are running 10.2.1 currently.

JonathanMori1

Hi, I know this is a little old, but I was having some of the same issues as you were. I was wondering why you decided to migrate from SDEBinary to SDEGeometry. I did the opposite and migrated to SDEBinary and noticed significant performance improvement.

TONIFAIRBANKS

We have a 32 core SQL Server with a MAXDOP setting of 6, which was set after we upgraded from SDE 10.0 to 10.2.1 and migrated our data from SDE_Binary to SDE_Geometry. We have started rebuilding our spatial indexes on our large feature classes, but are still experiencing SEVERE slowness while editing, especially when snapping. It seems to be worse while multiple users are connected and actively editing. The slowness is intermittent throughout the day, and slowness can be experienced by one user and not another during the same time period. If we export our data to a file geodatabase we do not experience slowness while snapping and panning.

Has anyone else solved the slowness problem or received a good answer from ESRI?

DawnSowinski

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.

This sounds like the problem I've been experiencing. The data is in feature classes on an Oracle based server in 10.1.1.... Snapping quits until a compression and we can't afford to stop editing to compress multiple times a day...

Yes, it's a bulky file with lots of parcels, but there is no network or massive analysis/queries being performed (or attempted), just simple editing. Trying everything I can find in these documents but nothing seems to work. Has anyone had any success in overcoming these issues?

Has anyone tried recreating the entire geodatabase since the upgrade? Any other suggestions?

MichelleBoivin

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

MichelleBoivin

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

BillLotz

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.

fsbusschers

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

jennifergordon

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.

MichelleBoivin

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

MichelleBoivin

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

ClintRichmond

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.

RobbHodges

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).

MichelleBoivin

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)?

MichelleBoivin

We are going through this exact same scenario here. ESRI just came in and reworked WATER's old database model and set up 6new datasets, including two new geometric networks for water and sewer. We are on SDE 10.1 SP1, SLQ 2008R2 and everything has begun to chug.

What we tried:
1) Turned off hyper-threading which made a noticeable difference to our users
2) Had them enable Classic snapping when editing, which helped
3) Enabled feature caching, which is actually suggested by ESRI when working with geometric networks (see article http://resources.arcgis.com/en/help/main/10.1/index.html#/Performance_considerations/002r00000004000000/) - this helped but is at a user level and we have over 300 users

What we tested:
1) Tested the drawing of all layers and performance of the processors on the server when using the networks (SLOW!), then turned those layers off and amazingly enough, things were better.
2) Also took a look at the Performance Monitor on the server and it appears that all of the hits were to the temp locations. If you read the article from above, you will notice ESRI says that a geometric network is now "executing a separate spatial query on the server for each feature class in the network. If coincidence is discovered, then network connectivity is established. The cost of maintaining the connectivity on the fly is execution of these queries, which can be expensive."

We have also checked the network (no issues), maxed database connections to over 64 (we were reaching 61 consecutive connections), and then all the basic info mentioned (normal.mxts, ESRI folders, etc.)

I believe this to be a performance "enhancement" on ESRI's part (sarcasm slightly intended) and they appear to admit that there is a large overhead now for geometric networks.

As for a resolution I am not sure. My thoughts at this time for us are to have a snapshot that is updated programatically on a regular basis for our general users (readers) so they aren't panning and "querying" everytime they try to locate a water main....but that's a business practice call....

I am glad to have found this post as I have been searching everywhere for information, so as I find out more information on our end I will post for everyone else.

I should also mention that our geometric network was created as a 10.1 network and was not migrated from a 9.3 network.

TimBarnes

Yep- It's slow for me as well. It doesn't seem to be network related par se as drawing speed is good (i.e. aerial photography and vector features) but selecting a feature results in a good 5 second delay, beginning editing is around 10 seconds- This is with all snapping turned off.

What I have noticed is that you have features in your map from a slower network location, even if they aren't turned on/visible, performance will be a lot slower- My working document is a mixture of local data, data from a networked machine in the same office and data from a networked machine in an office a long way away- After removing that data from the other office, selection speed and editing speed increased dramatically.

MarkBoucher

I just noticed the slowness when editing one layer with a 2' contour polyline layer on. When I turn it off the contour layer, the problem goes away. Certainly the snapping is "looking" around and has a lot to consider. Reducing the number of layers (features) that are turned on seems to help.

RobertoGallone

Enabling snapping (classic snapping)
http://resources.arcgis.com/en/help/main/10.1/index.html#//01m60000000z000000

ScottMoucka1

I occasionally have the same issue as Chad75 and there doesn�??t seem to be any rhyme or reason to when it occurs.

A map document will work just fine until I begin an editing session. As soon as I move the �??cross-hairs�?? into the map extent I get the Windows 7 blue circle indicating the computer is thinking. When this behavior begins Arc won�??t snap for the rest of the day. Doesn�??t matter which mxd I open, old or new, how many layers I have in the TOC or where the layers reside, server or local machine�?�behavior doesn�??t return to normal until I return to the office the next day after shutting down my computer for the night. A restart does not fix the issue. Outrageously frustrating!

Why hasn�??t an ESRI representative responded to this thread?

Joeysmith

The manhole featureclass is fine when editing locally.

KennethFoltz

I had significant problems with editing in 10.1. So much so that I was forced to go back to 10. It would initially run fine and then just start to crawl. I do not have this issue with 10, however. There is another tech in the office on 10.1 that doesn't experience any difficulties at all. None of the suggestions from ESRI (deleting .mxd, removing toolbars, etc.) helped any so for now, 10 it is.

AndrewBrown1

Has ESRI contacted anybody on this thread regarding their slow editing experience? I hate to begin any ESRI bashing here, but the "slow editing" has been around since 9.3.1. Previously, I thought it was due to editing features within shapefiles on a file system, but now I'm editing features that are stored in our SDE instance and the editing experience is still dreadfully slow. So slow, in fact, that my snapping tool doesn't even work. The only way to get around it, that I found thus far, is to open a new session and only drag in the layers that require editing, as well as a reference layer.

Pretty pathetic considering that this performance problem has been around for a while.

And no, it's not my network or server that is the problem.

HusseinNasser

Just to confirm that we have the same issue, Slow editing + arcmap crashes frequently with errors

Problem signature:
  Problem Event Name: APPCRASH
  Application Name: ArcMap.exe
  Application Version: 10.1.1.3143
  Application Timestamp: 5058f74e
  Fault Module Name: StackHash_4183
  Fault Module Version: 6.1.7601.17514
  Fault Module Timestamp: 4ce7ba58
  Exception Code: c0000374
  Exception Offset: 000ce653
  OS Version: 6.1.7601.2.1.0.18.10
  Locale ID: 1033
  Additional Information 1: 4183
  Additional Information 2: 418393d3a499c8ae8ed0a6df247c128b
  Additional Information 3: c8cd
  Additional Information 4: c8cd612dd071564a925536fa3384b159

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt

or sometimes this error

Description:
  Stopped working

Problem signature:
  Problem Event Name: APPCRASH
  Application Name: ArcMap.exe
  Application Version: 10.1.1.3143
  Application Timestamp: 5058f74e
  Fault Module Name: mscorwks.dll
  Fault Module Version: 2.0.50727.5420
  Fault Module Timestamp: 4ca2b820
  Exception Code: c0000005
  Exception Offset: 00163298
  OS Version: 6.1.7601.2.1.0.18.10
  Locale ID: 1033

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt

I understand this is a .net error as we have some custom applications on top of ArcMap written on .NET but still those applications were working just fine on 10.0 for more than 2 years.

Client ArcGIS 10.1 SP1, geodatabase 10.0

Any thoughts would be helpful!

Thanks!

aaronhill

Zone 111-
Renaming the ESRI folder didn't work for me? Any other processes have you tried?

aaronhill

So after renaming this folder did you restart your machine?

ChadMitchell

Finding the exact same here.
Snapping doesnt work like it keeps thinking (blue circle)
Editing small polygons, pick vertex, wait 25-30 seconds, I can then move the vertex, wait for the vertex to catch up 5-10seconds. Place roughly where it is supposed to snap on.
Noticed that it had built a good 175mb cache in roaming and 170 in local.

Also noticed when it auto refreshes the screen during the edit it just stops until you clip the refresh button. No different when used with/without hardware acceleration.

Removed all 3rd party apps installed Service pack slight improvement but still only as good as OEM 10.0

Fix didnt work for me unfortunately.

FrankBowne

Hi Everyone,
I as well had poor preformance with ArcGis 10.1. My IT guys tried everything on their end but I stilled had problems.
I contacted ESRI support and found that it was probabily a registery problem within ArcMap. Once this was corrected everything worked.

Here is the procedure we went through:

Following are the steps that helped us resolve the issue:
-Renaming the ESRI folder from the user profile:

-Close all Arc Map and Arc Catalog applications.
-Click on start and navigate to C:/Users /<User Profile>/AppData/Roaming/ESRI.
-Right click on ESRI and rename it as ESRI_old.

-Renaming the ESRI folder from Regedit:

-Close all Arc Map and Arc Catalog applications.
-Click on start and type Run in search window.
-In the run box type regedit.
-Navigate to HKEY_CURRENT_USER>>Software>>ESRI.
-Right click on ESRI and rename it as ESRI_old.

Hope this helps

JeffAzevedo

The snapping is pretty much unusable, and I'm not even running it on a Geometric Network, just a simple centerline edit.

Really surprised this isn't a hot topic... how does something that works this poorly not get caught before the release?

AmyGill

Opening, selecting, editing, snapping is painfully slow. I'm ready to uninstall 10.1 and reinstall 9.3 which will be time consuming considering I have three techs plus myself and around 50 ArcReaders. Then republishing. I'd really like to know is this is an acknowledged problem and if it is being worked on.

RobbHodges

Actually, I've noticed this is an issue with a particular featureclass (manholes) within a geometric network. I've tried exporting it out and importing back in...recreating the geometric network. No success.

The manhole featureclass is fine when editing locally.

The manhole featureclass is also fine when I delete the geometric network and edit it like that (on the server).

So, it looks like somehow, this manhole featureclass is causing issues when inside a geometric network and being edited on the server (I've tried another, offsite server just to see if I could duplicate that...and I did). The manhole feature class needs to be part of the geometric network, so taking it out is not a solution. Editing from my local is a hassle, because I'm having to share out the folder for someone else to edit.

RobbHodges

Nope, the new snapping is still unchecked. I have noticed more problems out of features in a geometric network.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.