Latest Contributions by DavidColey

Thanks Luci- not a problem.  Not sure if what you have here will work for me on the dijit since it looks like what you are works with a task, but I'm going to give it a try and let you know.  I know I can certainly use it on an interactive route task I have set up, where my work-around is to use a mouse-down as opposed to a click event when adding a stop or barrier graphic on my map, where mouse-down is a bit weird on touch screens Thanks- David ... View more

Thanks Robert- I hadn't worked with aspect yet, thanks for the heads up- David ... View more

Ah great thanks Tim, there they are-- David ... View more

A small update: The Recreate_All_Tiles option worked again last week (repeatedly using my python IDLE) on our stand-alone development server, but continues to fail with the same frequency and 'error moving bundle file' error in our distributed three-machine, 2 cluster production environment where our shares, directories and stores are stored on our 1Gig Lan connected file server.  It would be really, really great if ESRI could comment. David ... View more

You could try setting up a shutdown in your licence manager for all desktop products.  We use FlexLM and it does just that.  And to your earlier question, no I don't always have to stop services, only if a schema lock is set to true. And yes, you will have to overwrite or restart the map service depending on the nature of the change. ... View more

Yes, if anyone could actaully tell us what tools and/or scripts are used to generate the Summarize Within or Summarize Nearby GP services that would be very helpful.  Unfortunately, there does not seem to be any help in this regard in either the REST or JavaScript APIs.  As an analyst, I can certainly produce summary statistics on the desktop using a variety of methods and tools.  But that in no way helps us to construct the same GP service in our own Advanced-licenced Server environment which would allow us to create our own jobs. Thanks David ... View more

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