Latest Contributions by Brownschuh

Bummer, I was hoping there would be an arcpy function to test if a GDB is accepting connections.  Maybe ESRI can include that functionality in future releases? ... View more

My organization actually just migrated our scripts to a dedicated server. Before we had a similar setup to what the OP probably currently has; a server with an enterprise GDB/SQL and scripts set in Task Scheduler. In an effort to segregate separate GIS tasks/workflows, we stood up an automation-focused server. Honestly it's set up the same as we had it before ... scheduled tasks are still set up in Task Scheduler. No real issues with the new server setup. In fact scripts do run slightly quicker. Some of that might have to do with the newer operating system we migrated to. As for Notebook server, that's something I have been interested in exploring, but don't have any experience with at the moment. I'd also be interested to hear how other organizations are using it for their day-to-day operations. ... View more

Thank you for the reply.  We already use the AcceptConnections function to block or accept connections in our database maintenance scripts.  What I'm looking for is a way to check if connections are blocked/open. ... View more

I tried testing the approach above and could not get it to work.  Tried going from line to polygon and vice versa; doesn't allow for import.  Suppose it makes sense because the symbology for lines and polygons are completely different ... but I figured I would give it a shot because like the OP mentioned, it's quite annoying to match colors between layers with 100's of records ... ... View more

Was using a 10.5 machine and needed a basemap; encountered the same error message.  Running PatchFinder indicated I was definitely missing the TLS patch.  Installed it and error went away.  👍 ... View more

Thank you for the advice, I'll make a note of the machine ID in case it happens again.  I should note that I had a call with ESRI support a couple weeks ago and we went through the same steps as I had outlined above; and it hasn't broken since then. ... View more

Apologies for the delayed response, what with the holidays and other projects going on we got somewhat sidetracked.  To answer your question, we don't have any database views in our eGDB, so we can rule that out.  In fact, we actually went ahead and implemented the 'list approach'; basically just have a list of feature classes/datasets/tables hardcoded in the scripts that the analyze/rebuild index tools will run against.  While admittedly not the best approach, it did cut back on the nightly processing time.  One of the main issues is keeping up with the list to have the script run against; sometimes it's a bit of a guessing game with some of the lesser edited layers.  But I'm thinking something like this database summary dashboard may assist us with that task. ... View more

We ran the script again last night; took 20 more minutes than the previous run the night before. We definitely need to look into a way of optimizing the task. To address some items that you mentioned, we do indeed use the Rebuild Indexes tool. As for the testing of Remove Spatial Indexes and Add Spatial Index plus Remove Attribute Index and Add Attribute Index, we simply just haven't had time to mess with/test those tools yet. At the moment, my colleague and I exploring the idea of using editor tracking to determine whether a feature class needs to be analyzed/rebuilding indexes. The only caveat with that is that we have a decent number of feature classes that get edited updated nightly via python script; those don't have editor tracking enabled. And we wouldn't want to overlook those layers. Suppose a quick solution to that problem would be to add them to a list of layers to always run the analyze/rebuild index tools against. In any event, I'll keep our progress updated on this thread. It may be beneficial for other organizations facing similar issues. ... View more

Did you register the feature dataset as versioned after renaming it?  Not having it registered as versioned would produce that behavior.  Also, was there a particular error message it produced when y'all tried to edit the feature classes within? ... View more

In the past the script would generally take about 45 mins to an hour.  However, after examining the script a bit closer this week, my colleague and I determined that the loop for the analyze and rebuilding of indexes was probably not working properly.  Having made some adjustments to run the aforementioned tasks on all FC's, FDS and non-spatial tables, the runtime was well over 5 hours (rebuilding of the indexes was the one task that took the longest).  Now granted this may be because analyzing and rebuilding of indexes was not being performed on some layers; perhaps we will (hopefully) discover a much shorter runtime tonight with our testing. I would greatly like to use 'if-then-else' logic to determine whether or not a layer has been edited, but like you mentioned, I am not aware of an examples to determine this.  But in the meantime I suppose one workaround I could deploy is to use a list of those layers that are known to be edited on a regular basis and have those tools run against only those layers.  Not the best solution if we don't include those layers that get edited rarely, but could still work. ... View more

Thank you for the reply.  Glad you mentioned switching the order of where we have analyze datasets; after reading some resources over the past week my colleague and I planned on moving the analyze portion after the compress.  And based on your response, it seems as though we are doing what you recommend:  running analyze on all feature classes (regardless of where they live), feature datasets, and tables.  While this basically covers everything in the database, one thing we've noticed is that this really affects how long the script runs.  However, from what I understand, analyze and even rebuilding indexes should really be occurring on layers that have had edits performed on them.  Just for clarification, we have hundreds of layers in our database.  Some are edited heavily; many edits on a daily basis.  And other layers are never edited at all (basemaps, if you will).  Is there a way we could add some logic to our python scripts to run analyze/rebuild indexes on those feature classes/tables that have been edited since the last time the script was run? While the goal of our nightly task is to be as thorough as possible, I also don't want to waste time and machine resources with a script that takes hours to run.   ... View more