Latest Contributions by DavidColey

Well, there's not much to tell.  Prior to our move to SQL Geometry at 10.1, I found that for certain utilities feature classes like hydrants, there would be from time to time more rows in the business table than in the feature (f) table. I discovered that nugget as I was transforming data into Intergraph format via FME.   I didn't even think it was possible to create or otherwise load rows into a feature class using standard ArcGIS front-end methods and not create geometry, but it happened.  So it's not a primary key error per say, it's more of a key-constraint violation I would guess.  What I suspect had happened is that hydrants data, coming in from an xy event table created from a spreadsheet perhaps had inverted x,y's or were perhaps in a differenent coordinate system, or had differenent units.  But because we use well-defined x,y domains, resolution and tolerances I think the information was added to the A and F table but upon, reconcile, post and/or compress, the invalid values in the F table were dropped, but the business rows remained. That's my theory. ... View more

Hey Dave, I had something like this awhile back before we moved over to sql geometry, only in reverse to what you describe, i.e. more business records than geometry.  It was happening because certain editors were copying and pasting records from spreadsheets in a way that was violating the key constraints. Basically I set up sql scripts to remove the dups and clean any and all dependencies in both directions.  I've got some scripts somewhere, I'll see if I can round them up if you don't have this solved- ... View more

Hi Aaron- We have found that hyperthreading on the CPU must be disabled whether running SQL2008 or SQL2012 when using sql geometry, but not when using binary storage. We lost nearly half of our performance until disabled.  We also found immediatly that spatial indices matter greatly with sql geometry, especially for complex polygon datasets like a parcels layer.  The default grid levels(med x 4) and cells per object (16) did not perform well for us at all.  After disabling hyperthreading, we set up our dbTune with index levels of (med, med, med, low) with 64 cells per object.  We arrived at this level through trial and error as there still doesn't seem to be any effective guidelines- performance has been acceptable since. I had started a similar thread here, SQL Server 2012 and 2008: Geometry Performance - that asks if there are any performance gains when moving to 2012. SQL Server 2012 and 2008:   Geometry Performancehttps://community.esri.com/message/96614#96614‌ It's been viewed just a scant 23 times with 0 replies, although this post appears to have done just that- Thanks David ... View more

Wow Jeff, you didn't have to do this, but thank you.  ... View more

Thanks for putting this up Jeff.  Michael and I are trying to utilized the side panel popup to hold the results from a gp model that is returning fetures and graphics based on the linear distance from a selected feature, basically a select by attribute of an input layer then re-selecting user-input features base on a linear extent ... View more

Thanks Matt- Oh sorry all I did mean RECREATE_ALL_TILES, not UPDATE_EXISTING_TILES  in my earlier post ... View more

Good Afternoon all:  I have a status update on this issue.  On Friday, while working with Jon at ESRI Redlands, he was able to sucessfully re-create the behavior we have been experiencing regarding the bundle error move.  In fact, Jon reported back to me that he saw the same behavior at 10.2.1 which I found quite interesting as we never experienced a bundle error move at 10.2.1, only cache failures for a given extent which could always be reparied.  However, the good news is that this 10.2.2 bundle move error has now been logged as a NIM: [#NIM104348  In ArcGIS Server 10.2.2, you're unable to recache tiles while the existing tiles are being accessed. ] Which of course means the development team will now be looking at this issue.  In the meantime, we all can go back to caching identical non-production services either on an edn or on a production GP cluster machine, as long as that service is not being accessed, and then moving the new bundles to production using REMDIR and XCOPY bat's.  I have since last Thursday successfully completed three full UPDATE_EXISTING_TILES operations on a non-load basemap service of considerable cartographic complexity from scales of 577000k down to 1128K, both with and without the use of an AOI polygon.  Thanks- David ... View more

Thanks Nils, good to know- Davidd ... View more

Hi Nils- If you are using the attachment relate you have to keep in mind that the archiving doesn't traverse relationships on non-versioned data.  I think you'll have to disable archiving, enable versioning and then re-enable archiving. -David ... View more

No, server needs the data-store.  We have found that things are more stable if the connections are in a secure, shared environemnt.  So, even at 10.0 we always did the same thing.  What I think you're talking about is the option regarding data store connection same as publisher's connection (ie your desktop sde connection).  I personally don't like to rely on my C:\Users\dcoley\AppData\Roaming\ESRI\Desktop10.2 sde connections for publishing, particularly if another publisher needs to access the mxd.  So I get around that by always using the data-store connection from my desktop. ... View more

Yes I agree.  I've had to do that a few times and re-configuring the web adaptor has always worked for us- David ... View more

Go ahead and place your sde connection files and fdgb's in the server-registered data-store default location, either on your server or shared directory.  We use a subfolder in our data-store named DataConnections.  Then we define other various folders under data-store containing mxd's to be published. Each of those mxd's is always sourced to a DataConnection connection via unc path.  In this way, your published mxd's will always source your data-store connection and not various publisher's desktop connections ... View more

We've always gone in order:  10.1, 10.2, 10.2.1, 10.2.2.  Cache bundles worked at every release unitl .2  I'm working with esri now on a ProcMon for further discovery . . . ... View more

Hi Michael, no.  The bundle move error (which from what I see is really is a *.bundlex file not being moved from an arcgistemp folder on a gp machine in a cluster environment to a shared cahe directory) bundleissue is brand new at 10.2.2 (to us anyway).  I've never encountered an bundlex move error prior to this release since the bundles have been in existence..... ... View more

Thanks Matt, interesing result regarding the Exploded v Compact.  I too am working with Jon out of Redlands to get this solved.  We ran some I/O tests yesterday using IOzone and thus far have determined that throughput does not seem to be the culprit.  We will be running a ProcMon test later today and I will post the results ... View more