Latest Contributions by Bud

@KoryKramer I've clarified the question. Thanks. ... View more

Disregard. I don't have much experience with AGOL or Enterprise, but this might be a viable workaround for Enterprise: For Enterprise, you might be able to create a database view or a query layer that has a calculated field for LENGTH. For example, in Oracle, it would be: SELECT SDE.ST_LENGTH(SHAPE) AS SHAPE --other fields FROM MY_FC The same would apply for AREA: SDE.ST_AREA(SHAPE). I imagine you could publish the query to Enterprise and label based on that calculated field. Notes: If using a database view, you might need to register the view with the geodatabase. The problem with using a view or a query layer might be: neither is editable. If you want to edit the layer in Enterprise, then maybe an attribute rule could be used instead to populate a LENGTH field in the actual feature class. Just thinking out loud as a non-expert. I agree that out-of-the-box functionality would be better.    Edit: After re-reading your question, I see that you specifically want to publish a feature service, likely for editing. So the idea above for creating a query won't work. Please disregard. Can you create dynamic joins in Enterprise? For example, could you create a view or query layer that has a calculated LENGTH field, then create a dynamic join from the FC to the query, allowing you to still edit the FC in the feature service, but also letting you label using the joined query's LENGTH field? ... View more

Why are some bugs googleable, like this one: BUG-000085841 But other bugs aren't googleable, like this one: BUG-000140702 ? While that bug does have a permalink in the Esri Support Search site, I don't get any hits if I google the bug number or bug title. ... View more

Here's an example of a working subquery (has a correlated subquery with a table alias:  b ). roadinsptable.objectid IN ( SELECT objectid FROM roadinsptable b WHERE b.asset_id = roadinsptable.asset_id ORDER BY date_ DESC, condition DESC LIMIT 1 ) Source:  One-to-first joins: Control what related record is used Data: Bud_0-1677007900580.png   Video of me trying to write b.asset_id, but it auto-completes  b.  to  BEFORE or  BETWEEN (depending on the scenario), which isn't what I want. ... View more

Related: SQL Expression Autocomplete: Typing a period shouldn't autocomplete a word Definition Query SQL shouldn't autocomplete “when “ to “WHENEVER” ... View more

Related: Idea - Arcade Endpoint() function ... View more

@ShitijMehta  From the proposal -  tell me if I got this right - the proposed tool basically inserts one row at a time and adds value to different fields in that inserted row. Yes. To understand a bit more - What would be your workflow after this? My original intention was: Export the model to a Python script. Share the script with support or colleagues to easily reproduce exact troubleshooting steps. Example use case: "Are you able to script out your steps so I can try running the code exactly the same way because something in our workflows is obviously different if it works for you but I get an error."  (conversation with @JoshuaBixby ) Reason for using Model Builder, not writing Python from scratch: Time and skill level.  But I imagine there are lots of other use cases too. Does @BradySmith have anything to add? It seems like a no-brainer to me. We need to be able to insert individual rows using Model Builder -- just like we can do with any other automation platform/mechanism. Would you want to insert another row? which means you will rerun the tool again with different values for each field? Yes. Re-run the tool again to insert a handful of other rows. The newly added row will not have a feature associated with it at the point of inserting this new row/s. So, say we add two new rows, you will have to add a new feature for each row later or you are creating 1:many (1 feature and many rows for that feature?) "The newly added [feature] will not have a [geometry value] at the point of inserting this new row/s." That is correct when inserting features into line and polygon feature classes; the geometry column would be null in that case. But for point feature classes, we should be able to create a single-part point geometry by entering X and Y coordinates into the tool. And of course, if we're inserting a row into a standalone table, then there isn't a geometry column, we'd only be populating non-spatial columns. Regarding, "...or you are creating 1:many (1 feature and many rows for that feature?)": I don't think I follow. I don't think related records have much to do with this idea. The tool would either create new features in a feature class. Or new rows in a standalone table. I don't think related data has much to do with the core idea. Thanks! ... View more

Esri Canada Case 03257552  Create view ... View name gets cleared when run BUG-000155888 - In the Create Database View geoprocessing tool, the Output View Name parameter is cleared when the first click after entering the Output View Name occurs outside of the tool interface. ... View more

@DuncanHornby For true nulls, the text could be italicized, a lighter grey color, or something like that. ... View more

These related posts might be of interest: Arcade Code Review: Set polyline M-values to cumulative length of line Arcade docs: Working with vertices ... View more