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; } } }

I have a polygon ArcSDE feature class (in sql server) that is drawing very slow.

ShannonSmith5

It has about 78,000 records. We are using 10.3.1. This is the only feature class that is slow. Generalizing the data is not an option. And I have tried adding the data to its own basemap. Also when i export the data to a file geodatabase it is super fast. The database is compressed nightly.

Find more posts tagged with

Accepted answers

All comments

JoeBorgione

Have you compressed your database lately?

ShannonSmith5

Yes, the database gets compressed nightly.

Christian_Wells

What state does the geodatabase get compressed to?

If the state is other than 0, are there a lot of records in the Adds/Deletes tables following the compress?

ShannonSmith5

Right now it is at state 30. I can't get to state 0 right at the moment because of a couple of versions that cannot be deleted because of long term editing. Any other suggestions?

MicahBabinski

Hello Shannon,

Two thoughts come to mind:

Do the features contain many polygons that snake all over the place? Polygons with very complex edges (lots of vertices) that stretch over a large part of the feature class' extent will be very hard to index efficiently. If this is the case, it may be worth splitting up the features by some sort of regular boundary, like township. This may improve your drawing performance.
How many attributes does the feature class contain? If there is only one attribute that will be queried, convert the data to raster and it will draw super fast.

Otherwise, it may be worth researching the problem with the specific version of SQL Server added to your search terms. Or, if you have one, ask your SQL DBA if there is anything in the database that might be causing the problem.

Good luck!

Micah

mody_buchbinder

The first (and easiest) test is to copy & paste the layer into temporary layer in the same geodatabase.

If it draws fast then delta tables/states are the problem. If it draw slow then the features are too complex.

In that case try to zoom to different areas. Usually there are just a few very complex polygons. If you can split them it can solve the problem.

Have fun

Mody

ThomasBuchmann1

Are you using the GEOMETRY Spatial Type? Have you checked the Spatial Index? the BoundingBox has to fit the FeatureExtent of the Feature Class.

We also encountered problems with the Spatial Indexes. And with the newly AutoGrid-Index in 10.3 it got even worse.

We always change the Spatial Indexes away from the AutoGrid to a manual 4-Level Index (for our data the best setting is LLLL / 16).

Esri's idea to prevent us from the complexity of the Spatial Index is imho a very bad idea 😞

AlfredBaldenweck_0-1739401220133.png

Robert_LeClair

In addition to Compress, I'd recommend the following data maintenance tools:

Analyze
Analyze Datasets (both as data owner and SDE (system tables)
Calculate Default Spatial Grid Index

Good luck!

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.