Latest Contributions by DavidSolari

CSV files have an effectively unbound length per field which is why dumping them straight to your EGDB picks that data type. You'd be better off extracting the data to an intermediate table in a File or Mobile Geodatabase where you can clean up the data and schema before loading it into your EGDB. If you're genuinely concerned about database performance you'll want to prep your schemas by hand, then use Append to transform the CSVs into the new format. ... View more

Try flipping back to DEFAULT and changing the entry_note to a brand new value, does that prompt a conflict? ... View more

This should be possible with a bit of arcpy, look into Cursors and the Geometry objects. ... View more

Excellent, that's progress! If your relationship is working, it's possible you don't have any features. You should add a guard by checking if the Count of the relatedRecords is zero and returning early, but if your test data should return a related record then sort out your relationship query before you do that, otherwise you'll bury the true issue. Good luck! ... View more

Sadly no, and there's no news of a multi-choice domain type on the horizon. In this case you'd need a many-to-many relationship class between the easements and each of the choice tables, then do some stuff with calculating data or attribute rules into a redundant field to get the final table. ... View more

One-to-many relationship classes should work here, but something that works in ArcGIS Pro might fall apart once it gets into a server based workflow due to edit tool limitations. It looks like you just want to tag every easement polygon with an Owner and Type, with a set list of options for both. In that case you might want to use Coded Value Domains to lock those options in, then you can filter on those two fields instead of trying to do relationship-based selections. ... View more

From my testing, replica synchronization (i.e. what offline areas use to update the feature service) appears to attribute rules as series of individual features to C/U/D. If FeatureSetByName is reading the data outside of the current transaction, it'll just see the pre-sync snapshot which will not include new features or changes to those features. If it's reading data from within the current transaction, it might see the other operations but it might not, depending on the execution order, so you should always assume it can't. The safest option is to assume that this type of query could or could not contain the current feature; therefore, always read/modify the input feature in addition to what you get from the query, but also assume this could result in a duplicate action and guard accordingly. This will cover both standard and sync updates. If this'll bloat your scripts too much, test how the rules behave in your environment from a variety of clients, offline and online. ... View more

Also, I'm not sure you can return an object like that in rules, you need to return an object with a "result" property which in turn has at least one of "attribute" or "geometry" properties. The docs have more info on this. ... View more

FeatureSetByRelationshipName doesn't use the name of the relationship class object, it uses the name of the relationship as defined by the forward or backward label in that class. You can try using that name or switching to FeatureSetByRelationshipClass if that's supported in your environment. ... View more

You can try using the "geometry" and "geometryType" parameters to add a spatial filter to your requests (docs). Assuming the service has a properly maintained spatial index and your query geometry isn't too complex this should give you a much smaller working set. ... View more

Check out the format codes for the format-date function. ... View more

The simplest way is to extract all your unique IDs and associated info to a CSV file, add that to your Survey's media, then use the techniques listed here to calculate the other fields. I'm almost certain this requires Connect but I highly recommend learning the full Connect workflow anyways, it'll save time in the future when your client's "basic" survey needs extra features bolted on. If you need to update that CSV data, you can either generate new files and republish the survey, or you can publish the CSV to your portal and link it to the survey for real time links between the portal data and everyone's survey. There's also ways to pull directly from a feature service, but that requires porting all your shapefile data over and it's a bit flaky when a survey is collected offline. ... View more