Latest Contributions by RayChilcote

Joseph Rigley, Blair Hornung I upvoted this a decade ago.  It would be a nice-to-have.  Not denying that. It sounds easy.  A dbf or access database is one thing.  Countless RDBMS's that do not allow changes in place is another.  Granted, Esri could make it available where it is easy to get accomplished.  But I do not expect it to be accomplished any time soon on RDBMS's. I gave 2 avenues to get the end result.  I shared because some don't know fields can indeed be reordered (albeit not in place). ... View more

First, reordering fields is possible using FeatureClassToFeatureClass.  Granted, this is not in place reordering.  But reordering is possible.  [create reordered copy via FC2FC, delete the original, rename or copy the reordered dataset, apply permissions and indexes as appropriate).  To boot, it's not very difficult. Second, X-Ray can reorder fields. Last, in old school apps run on databases, it was up to the app to create the field order.  This was because more than one field order could be required for any given table (feature class).  I don't see where this has changed.  ArcMap, ArcPro, and ArcServer all allow reordering of fields.  Yes, just in the mxd (not in the originating database).  But it's on the app developer to create the field order desired/required.  For that matter, they can (proactively) also turn off the visibility of fields not needed (in the app).  That doesn't seem to be happening anymore.  That isn't a database problem. Lazily grabbing all fields and throwing them in an app with the default order is like doing a SELECT * instead of selecting each field.  Simply a bad technique.  Same goes for dropping a feature class into any app.  Expect the order to not be the way you want and move them in the app. ... View more

The above tool looks great.  But much like the unsupported GDBT State Tree Diagram tool, it will become dated.  I do not mean to darken this light of sunshine.  When changes come (say Branch Versioning), will this code be updated?  For certain?  If it were part of the product, the answer would be yes. Esri said it would incorporate the GDBT into the core product.  They did so for 80-90% of the product.  Just not the tool most desired. It should be in ArcGIS and supported by Esri in future upgrades. Again, I don't mean to belittle your effort.  The labeling alone is awesome and allows for much more flexibility.  A tall tree is going to apparently snag me.  Large enterprise environment. ... View more

Since traditional desktop days are limited, I doubt Esri will create the tool there. Therefore, I created a new idea for the State Tree Diagram for ArcPro.  Perhaps 6 years from now, we'll still be wondering where it is... https://community.esri.com/ideas/17041-state-tree-diagram-for-arcpro Long live the State Tree.  Hopefully the seed will take root. ... View more

I second the thought to look for NoData (NULL, "", NaN, None) and zeros. Are your rasters for the 7 inputs the same size?  Do they have a commonality or a method of relating one to another?  Or are you having one raster intersect another?  If they are of a common size and can be related, do the relationships/intersects and calculations outside ArcGIS and only pull in the result. ... View more

I hadn't thought of it before, but it would be nice to set up a trace to determine the query being made to fulfill the table.  This would show why the error is being made.  Well, it would lead us to some answers. It appears that there are several different cases here that are throwing the error.  In other words, the query can likely fails for several reasons. I had this error pop up again this past Monday.  The cause was unmatched rows.  I had one row in state_locks and the other in Object_locks.  There were no matching rows for either in process_information. [Thanks again Matthew Boyle for the query!]  Once I got rid of the two rows, all was good. Btw, I'm still against Esri ignoring the error  [what is "the fix"?].  If there's an error, then there's some incongruity in the tables.  I don't want the error covered up.  In my case, the question becomes why are the two rows still there? ... View more

Thanks Bill.  Was hoping someone heard what the actual "Fix" is. NULL shows that there's something amiss in the tables.  I'm really hoping the fix isn't hiding that error.  Could change from a minor/moderate problem to catastrophic.  Especially if the true issue is identified after weeks or months. ... View more

Do we know what the "Fix" is?  I don't want the error hidden.  I want to know what is broke (which states/locks/processes are having issue). One cause is orphaned states.  If there are edits being lost, I want to know.  I don't want loss covered up and with the feeling "everything is good". ... View more

We've had the NULL issue at NCDOT.  The source of our issue was a hanging service layer lock.  However, I can see this happening in several areas of the ArcGIS SDE environment, namely due to processing speed.  A database equivalent is a Deadlock.  But here changes have already been made to sde_states or its related tables.  Some tables get updated but others do not, thereby unassociating the state/lineage/lock/processing information. For a read on other reportings of the issue and a semi-fix: https://community.esri.com/thread/206938-error-trying-to-view-locks#comment-739912 The large query in the thread is extremely useful to find and locate the offending rows.  Removing them makes ArcCatalog happy again.  But like my comment in that thread, beware.  While removing the rows makes SDE happy again, you are removing something.  If they are orphaned (unassociated) rows of states/lineages/locks that have already been posted, your data is likely safe.  Alternately, you could be removing states of unposted data, which you are then removing work that is going to be lost.  You may/may not have further work with the version (which now may be unusable) and/or route locks. Bit of bad news: according to the above thread, this isn't fixed in Pro.  An Esri employee says it doesn't exist at 10.6+, but several users report the issue remaining (including in Pro).  BUG-000110574. My big question is: if Esri says they are going to fix it... what are they fixing?  Will the NULLs that cause the "Column value is NULL" error just be ignored?  Or are they deleting unassociated rows?  Or...?  Any of these are impacting to us. ... View more

Did you have a solution to this error? ... View more

Yes, stopping the services is part of our process for maintenance.  But this does not get the lock that isn't even showing.  Until we stop the ArcServer Machine, the lock will persist (no changes can be made). In prepping for maintenance, we have traditionally first checked ArcCatalog locks. Admittedly, I haven't checked all the locks tables in the middle of our maintenance though (usually just the version/object lock relationship).  If there are any problems after that, we immediately move to stopping the ArcServer Machines.  I'll definitely look into all these locks tables during our next maintenance cycle.  Perhaps there's something to be found.  Gutting them out is an excellent idea. ... View more

An SDE schema lock owned (caused) by an ArcServer service.  But the lock doesn't show up in any of the locks tables. Perhaps too much information follows.  But maybe somebody will benefit... By design (in our case, Esri's Roads and Highways extension), an edit by a service is meant to be very short lived (and the lock short lived).  But instead of releasing the lock, on rare occasions the lock remains.  Almost more like a physical lock is retained, but the lock rows are no longer in the locks tables. The feature class in SDE becomes locked by this ghost lock (better term?  If there's a more proper definition or insight to what this is, let me know.). We saw this as early as 10.3.1 when refreshing data from our Editing tier to our Publishing tier.  A feature class (or many) on the Publishing tier could not be altered (renamed, deleted, most any schema change).  Yet there were no locks in the locks tables.  We stopped and started most every piece of hardware.  Stopping and starting individual services would not release the lock.  Finally, the ArcServer Machine was stopped and started.  Then voila, the lock would release.   Our editing services tend to reveal a little more insight.  After one of these ghost locks occur, the other load balancing machines then (also) retain a lock (maybe they are getting in line behind the ghost lock?), these can be seen in the locks tables.  We end up seeing repetitive locks, building up to match the number of load balancing machines.  They will not be released until the ArcServer Machine causing the issue is stopped and started. We have not seen any database Deadlocks during any of this. I'm also throwing out a warning to everyone.  If there are Nulls in the locks tables, there is an issue somewhere.  Find the cause, especially if it can be repeated.  We've pinpointed ours (above).  While reconciling all versions, it will error on one that has a service lock.  We will not Compress after, as that is what creates the NULLs in question (for us).  Second warning: editing after the failure can introduce conflicts. ... View more