Latest Contributions by DavidColey

I know this is a bit late in the game and hopefully not too obvious, but by setting up your dojoConfig var within a script tag of your html and setting up your packages, async and parseOnLOad options we've never had any issues:     <script>       var path_location = location.pathname.replace(/\/[^/]+$/, "");       var dojoConfig = {       packages : [{name: "agsjs", location: path_location + "/agsjs"},       {name: "js", location: path_location + "/js"}],         async : true,         parseOnLoad : true       };     </script> Thanks, David ... View more

Sure.  Um, well as you know caching is very I/O intensive for enterprise databases.  You can try a couple things: First, if you must use your SDE as your source layers, try backing out some of your more intensive layers such as parcels, annotation and the like and run some high-level tiles and check your performance.  Then keep adding in layers and labelling combinations until you can find the offending layer.  Or, if you can, go ahead and copy your cache layers to a fdgb that resides in your data-store, resource your mxd to those layers, re-publish your service and then re-cache. For us, I found that for our county basemap, with scales down to 1:600 (for 600 mi2), cached at about 4 hours when running a full 14 caching instances on our gp server.  Again, that was when sourced to our enterprise SQL SDE. When I replaced the source to fgdb in our data-store, that time decreased to 20 minutes. Hope this helps David ... View more

Hi Mike- Could you provide a bit more info on 'stalled processes'?   Can you supply an error message?  Thanks David ... View more

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