Latest Contributions by DavidColey

oh good, sql and sde do not like hyperthreading.  Hyperthreading killed one my sql updates,  I think when we went from 2005 to 2008r2.  Could not figure it out until I found an obsucre thread in the old forums and sure enough, one of the admins had enabled hyperthreading on the database server... ... View more

Aaron, maybe a dumb question but you all don't have hyperthreading set up do you?  ... View more

Ah, that's it.  Thanks Chris and yes I'm looking forward to your GIT ... View more

Great, thank Chris.  Hmm, yes the jQuery example - there is clearly a lot going on in it.  I'm not sure I understand how this is bootstrap and not just jQuery... ... View more

Hi Chris, I'm following the group but have yet to join.  My name is David Coley, I am the ArcSever Admin for Sarasota County, FL where I also work as the app developer along with my sde admin and colleague, Michael Stranovsky.  I am an MS in Geography from the University of Florida (2003).  We have some 9 focused javascript apps that work very well on the desktop and, while mobile-friendly, are not platform responsive(yet!).  I need to incorporate bootstrap but don't quite know how to do that yet.  Anyway, that's why I want to follow the group and will certainly join. Here's an example of one of my lookup apps: Sarasota County Public Works Thanks- David ... View more

Really?  Wow that's tough Aaron, I now see where you're coming from.. I've asked ESRI on several occasions to chime in on spatial index tuning params when using sql geometry with no feedback. I don't think they know.  Perhaps Vince Angelo's Blog can chime in here.  For us, we did find that our spatial index tuning did solve draw and snapping problems on our larger poly layers, and (again for us) sql 2012 handles sql gemoetry better than sql 2008.  I don't know why: a columnstore index on the geometry column that didn't exist at 2008?  But if that were the case wouldn't things work better for you? David ... View more

Absolutely, an we would like to leverage AD as well.  It's definitely a priority for us moving forward and I will certainly post back any info/results to this thread... ... View more

That's fine George, I was not unclear.  We purposefully moved to SQL Geometry at 10.0.  I am simply trying to explain to the community that spatial index levels and number of cells per level does have a performance impact.  We were able to solve that impact by tuning our levels and counts and I am just trying to pass that info along. David ... View more

Sure I understand.  We define all of our storage parameters upfront in our dbTune tables for location, type, page fill params, spatial index params and more and assign that to a VECTOR keyword.  Whenever we import or otherwise create data we simply use our keyword and in that way we are consistently set up across all of our user instances.  We moved away from SDEBINARY storage at 10.0, and after initial struggles isolating our performance issues (disk raid config, san vs local array, network I/O, indexing) using SQL GEOMETERY storage, found that the spatial index parameter adjustment had by far the greatest impact on our performance. For example, our parcels layer was never super speedy even stored as sdebinary, but was initially terrible at sql geometry.  After eliminating disk R/W, network I/O, memory paging, sql system database locations (esp temp db), primary and secondary data file storage locations and transaction log settings we found that the resetting the spatial index levels and cells per object greatly increased our desktop performance when usgin SQL GEOMETERY. David ... View more

What I mean is that when I publish a gp tool, I make sure the mxd itself and the data connections (or database in the case of a fgdb) contained in the mxd reside in the registered data store location... ... View more

Aaron - what do you mean 'The fact remains that SDE performance was better at SQL2008R2.'?  We have not found that to be the case at all, in the fact the opposite.  I replied earlier in this thread that tuning the spatial indices from the default Medium and 16 cells per level setting at all levels did not work well for complex polygon layers with lots of vertex and area variability.  For these layers, we did find that index of Medium, Medium, Medium, Low with 64 cells per object greatly outperforms the default setting at both SQL2008 and 2012. For point and polyline layers, we found no impact in draw and query times between our adjusted levels and cells per object and the default setting. David ... View more

Are you sure everything is running from a registered location?  Are you getting a clean result from the results window in ArcMap from which to publish the tool? ... View more

good to know, thanks ... View more

That is good news Michael! ... View more

glad to help ... View more