Latest Contributions by RichRuh

This isn't something we've seen before. In theory, we know what is causing this; the error code tells us that the Variant's type isn't valid.  In practice, we don't know what could be causing this. If you have a consistent, or sometimes consistent, reproducible case, could you please log it with support? Thanks, --Rich ... View more

Hi Bart, I wrote a few lines of code and was able to select 500 features using FeatureLayer.Select(queryFilter, SelectionCombinationMethod.Add), where the queryFilter returned 200 rows at a time.   This was with a feature service workspace.  Could you tell me more about what kind of data source you were using, and how you went about selecting the records?  Code snippets would be fine. Thanks, --Rich ... View more

Luke, I'm not sure I understand the question.  You can get a Table object from a Geodatabase object using OpenDataset<Table>.  This is true if the Geodatabase object comes from a file geodatabase, an enterprise client-server geodatabase or a feature service geodatabase.  What am I missing? --Rich ... View more

Hi John, If you have a row and want to get the asset type, you can always call UtilityNetwork.CreateElement(), followed by Element.AssetType.  That's certainly guaranteed.  But if you're trying to create a row and want to fill in the asset type, the best answer for now is to use the field called ASSETTYPE.  I'm not aware of a case where this would not work. I agree that the API should provide a more formal mechanism for getting the asset type field name.  I'll put it in the backlog for a future release. --Rich ... View more

Luke, If you publish a table as part of a feature service, you can use another layer on that service to get a Geodatabase pointer.  Once you have that, you can use gdb.OpenDataset<Table>(name) as you would expect. The only thing to look out for is the feature service will change the name of the table that is exposed.   --Rich ... View more

It's in our roadmap to be sure, but unfortunately no plans for the short-term. ... View more

The best practice is definitely to call Dispose on Row and Feature objects.  Keeping these objects around in memory can cause the system to hold onto file handles or database connections. ... View more

As an aside, the FeatureClass, RowCursor, and Row classes all implement System.IDisposable.  For correct object lifetime management, you should wrap usage of those variables in a using block. You may have simply removed that code to simplify the sample, but I wasn't sure.  (This does not have any impact on the actual delete bug). We're planning on clarifying this in the geodatabase conceptual documentation in the next release. ... View more

As a workaround, you should be able to use the EditOperation.Delete(MapMember, Int64) override, using the layer and ObjectID. ... View more

Hello Berend, We've confirmed that this is a bug in the Pro SDK.  The workaround for now would be to refetch the features using the object IDs from the rows. It is too late in the Pro 2.2 development cycle for us to fix it in that release, but we will target a fix for 2.3. --Rich ... View more

Just to confirm, this method will be available in Pro 2.2. ... View more

Bart Van Hoecke‌ and I have spoken offline.  We believe that the new returnServiceEditsOption available in the feature service at ArcGIS Pro 2.0/ArcGIS Server 10.6 will solve his problem. ... View more

Hi Taner, ArcGIS Pro does not currently support plug-in datasources.  This is an active R & D project that we've been working on.  It won't be ready for the summer 2.2 release, but we hope to make it available in a subsequent release. --Rich ... View more