Latest Contributions by DavidColey

Greetings all, Did anyone find out about this issue at UC? ... View more

Sure thing.  The only time that I must stop services in our workflows are when those services have to persist a shema lock, as is the case with mobile and feature editing.  But in those cases the mobile and feature services are being sourced directly to a version in our edit sde instances.  I didn't realize you were still on IMS, but as far as schema changes go:  they should be planned and infrequent and when they do occur you will need to overwrite your map services.  Further, if you are that concerned about losing data, then perform some type backup prior to fdgb removal.  As far as Tyson's comments are concerned, we have succefully employed  full versioning and replication (we replicate via historical archiving) workflows since 2007.  Don't get me wrong: over 95% of the data in our dynamic map services is sourced directly from our production sde,where data syncs occur weekly to production and data is never out of date- Thanks David ... View more

I would have to agree with Vince on this. I can tell you that when you set up your SDE repositories (at least in SQL) as either SDE or DBO (depending on your model) sde or dbo will own the system tables.   For example, since we use direct-connect, DBO owns all the SDE system objects.  But once you add a headless user, and assign object-ownership rights to that user through your rdbms, all user GIS data will then be owned by that user as you 1: connect to your user dbs as the headless owner, and 2: then load data (featurdatasets, featureclasses, tables).  This way, all user-schema changes have to be performed as the data owner while administrative tasks are performed as SDE (or dbo) protecting integrity and performance- David ... View more

I'm sorry but this seems like a solution that is looking for a problem.  Per best practices (and you can ask Mike Jensen at ESRI), in ANY rdbms, you should be creating and using a headless data owner in your rdbms, then assigning privileges appropriate to that owner.  DBO or SDE should never own the data or schema, and unless each of your users is an sde administrator themselves capable of understanding and managing sde geodatabase objects, versioning, states, etc. they should never own data either.  For example, on our production geodatabase, GIS owns all data.  Users and AD groups are placed in view-only roles.  Our production geodatabase is actually the child gdb of our 11 edit user database instances, to which we replicate data weekly.  In each of our edit database instances, each utilizes a headless data owner and users are assigned to editor roles with view, create, update and delete privileges. Thanks David ... View more

Hi Matt- No, just the cache directory for the service.  I delete the service, then delete that services' cache folders.  You may or may not have to stop each ArcServer.exe process on each of your site machines (ie stopping the site) in order to delete the services' cache folders'.  We found that we had to in order to remove the services' cache folders containing the corrupted bundles because windows would not let us completely delete the directories otherwise.  Robinson at ESRI contacted me yesterday asking if I was seeing the same behavior (when running the ManageMapTiles Recreate or Delete Tiles) from both python and catalog to which I responded yes I am- David ... View more

What about for encoding geodatabase behaviors such as ID generation or auto-generating related geometries such that the behavior is independent of geodatabase type.  Much like the old CASE-Visual C++ tutorials ... View more

Yes, we use to use this all the time to track down orphan states.  Please bring it back Thanks David ... View more

Hello- Yes we experienced the same issues as well with our distributed site when we moved to 10.2.2 as well.  We also moved to .2 for the same reason - promised 10.2.1 slowness fixed that never seemed to materialize.  As such we moved all server directories (config, data, system etc) off of our SAN share and onto a local array of raided disks and then re-establihsed the shares. This did seem to allivate some of our issues for a few days, but alas not for long.  So what I have taken to doing for workarounds is to script local fdgb copy proceedures from a staging environment to the data-store for heavy I/O traffic layers such as parcels and tax roll info and spatial views to relieve some cpu pressure off our SDE.  That has helped considerably but ideally I shouldn't have to resort to these types of programmatic gymnastics.  More:  because we use a three-server site with two clusters, I typically set my map services with zero minimum pooling instances.  This is a known issue now with esri as far as service overwrites are concerned, whether the data is sourced from SDE or from a data-store fgdb.  So in when I do overwrite, I first dial up the minimum instances to one, then after the overwrite succeeds, I return to zero.Even so, I have still experieced dirty overwrites (leaving behind service .glock files that can only be removed by stopping the ArcServer.exe proccesses on each machine) from time to time if I overwrite large services during peak usage hours - so I don't do it. Lastly, see my thread Manage Map Cache Tile: Errors at 10.2.2.  We have yet to be able to overwrite an existing cache- regardless of source - without receiving 'error moving bundle' and completely corrupting the cache.  I am in communicaiton with esri on this one but havn't heard back from them in many weeks. I hope all  of this helps the community- Thanks David ... View more

Hi Sarah- We use a combination of python and bat scripts to accomplish exactly what you describe for layers that experience tremendous I/O. thereby relieving our SQL SDE of large cpu loads.  Each python script loops through feature datasets in my staging fgdb's stored locally on my dev pc, deletes the desired fc's, then either copies or imports (depending on the data and relational dependencies) the same fc down from our sde.  The scripts then update spatial and attribute indices (if import method must be used).  Even for large datasets such as parcels and tax rolls, all of this takes less than 5 minutes.  I then use bat scripts to remove the fdgb directory and xcopy in the staging fgdbs, usually in less than one minute.  If map service must hold a lock on the publicaiton data, the arcgis utitlity scripts for stopping and starting the service is employed as part of a bat.  This is performed nightly for some datasets (such as for property tax rolls), weekly for all others (such as streets - we empoly a weekly replica sync from our edit to production sde gdbs).   And forgive me for saying so, but this is a quite robust method and I have yet to experience a failure not caused by my own user error.  Please keep in mind that all shared directories must be setup with the appropriate permissions for all participating directories. Thanks David ... View more

Hi masoodkhadri- I don't think you can.  I think you have to remove the user from LDAP as once you've brought LDAP or AD in as your user store.  I could be mistaken, but we could not do that.  You can remove the user from any of the server roles, in effect removing the user.  Thanks David ... View more

Hi Mattias et al - No sorry I have not.  I have a request ticket in with a Robinson at ESRI but have not heard back from him in many days.  So for us, nothing has chnaged since June 6 sorry to say.  I'm certain this is a bug but am not expecting much back from ESRI at this time, esp with the UC coming right up.  Unfortunate, as I'd really like to get a NIM created for this.  As Mattias says, if anyone has found a solution for the bundle move error please share.  As far as the extent error you are receiving, I have had that occur when in earlier releases when using an AOI fc.  I was able to stop the error by either keeping all my cache data and the AOI in a fdgb, OR by keeping all cache data and the AOI in our SDE.  I always received the extent errror when I mixed them- David ... View more

Yes you are correct... ... View more