Latest Contributions by RichRuh

Charlie's code will get you the ArcGIS.Core.Data.UtilityNetwork.Element object that corresponds to a feature.  This is used for editing associations, setting starting points and barriers, and getting results back from a trace.  It does *not* give you access to the fine-grained topology for that feature.  For example, if a linear feature representing a conductor consists of five edges with taps between them, you cannot get back the five individual edges.  This capability is not yet exposed through the utility network.  ... View more

Hi Thomas, Gintautas is correct (you can also use StandaloneTable.Select).   --Rich ... View more

Hi Kyle, The first thing I would try is to change the call to FeatureClass.Search as follows: using (var rowCursor = featureClass.Search(editedRowsQuery, false)) This creates a non-recycling cursor, which is what you want for editing. Recycling cursors are described in more detail in the conceptual doc. I hope this helps, --Rich ... View more

I'm asking some colleagues, but I don't have a ready explanation.  If you made any progress putting together a reproducible case for tech support, I'd love to take a closer look.  ... View more

In the next release, Pro 2.3, anticipated in early 2019, we've changed Geodatabase.OpenRelationshipClass() so that it works with all geodatabase types, not just feature services. --Rich ... View more

This link should help: https://support.esri.com/en/contact-tech-support#us  --Rich ... View more

Your code looks fine. I going to guess that editOp.Execute() returns False, and that editOp.ErrorMessage contains a string that may or may not be useful.  My guess is that the Editor is having the same problems finding the field "DEPOTAREA" as the original code. I'm out of ideas.  Could you send this to text support with some data and a code snippet?  You can add my name so that there are no delays routing it to me. At this point I need a debugger to take a closer look. Thanks, --Rich ... View more

I don't think you're doing anything wrong.  At this point I'm just trying to narrow down what isn't working and hopefully provide you with a workaround.   Do the other fields (GRIDNO, LocalMunicipality, SettlementArea) have mangled names when you use .GetFieldDescriptions(), or is it just DEPOTAREA?  Does DEPOTAREA come from a different source table than the other fields? One more thing to try is to fetch the row and edit it with Editor.Modify() rather than using the Inspector.  If nothing else, that will help us determine if the Inspector class is causing the problem or if the problem is at a lower level. If there is an easy way to package up some code and data that reproduces the problem and submit it to technical support we can do some of this experimentation on our end.  Thanks for your patience. --Rich ... View more

Have you tried just using FeatureLayer.GetFieldDescriptions() to walk the list of fields and see which fields are available?  The only thing I can think of is that the field is being renamed because of the join. ... View more

Hi Dale, I spent some time looking into this. It turns out that using Geodatabase.ApplyEdits() will create an editing transaction, which will add rows to the SDE_states and SDE_state_lineages tables. This will occur even if the call to ApplyEdits() is completely empty. gdb.ApplyEdits( ()=> { // nothing here });‍‍‍‍‍‍‍‍ What you should be able to do is take your editing code and remove it out of ApplyEdits() entirely. This will result in writing directly to the database without any transaction management. I was able to try this (I used an add-in, but it should work in a CoreHost application as well), and it worked without adding rows to the states tables. You really do give up all transaction management though. edit1(); edit2(); edit3();‍‍‍‍‍‍ If edit3 fails, edit1 and edit2 have already been written to the database. If you did gdb.ApplyEdits( ()=> { edit1(); edit2(); edit3(); });‍‍‍‍‍‍ then an error in edit3 would cause edit1 and edit2 to rollback. I hope this helps, --Rich ... View more

The first thing I would do is to try hard-coding an assignment to the DEPOTAREA field in code.  E.g., insp["DEPOTAREA"] = "value here";‍ Where "Value here" is a valid domain code for the depot area field.  I *think* the code is crashing on this assignment, not inside GetIntersectingField(), but this would confirm it. Then I would check to make sure there is a field called DEPOTAREA in the result, and that the index of the field makes sense. ... View more

James, This will be fixed in Pro 2.3, expected early 2019. --Rich ... View more