Latest Contributions by Bud

Regarding Make Query Table event layers: If the first table in the list of tables/joins is 1:1 (i.e. only one row per record), then the columns from that table should be editable. For example, that's how it works with Oracle views (outside of ArcGIS): views are editable via SQL if the data is 1:1. Reason: We have use cases where we want to query data for the purpose of filtering certain records as well as utilizing supporting information from other tables. And we want to edit the data while doing it. Yes, that can be achieved with in-map joins for simple cases -- such as only joining on a single field. But for more complex cases like joining on multiple fields, a Make Query Table is the only option. So it would help if we could edit in the resulting Make Query Table event layer. Note: Other event layer types such as route event layers (linear referencing) are editable. Why not allow editing in Make Query Table event layers too?   ... View more

This post might interest linear referencing folks — as a way to find possible duplicate LRS events: Select duplicates (including near-duplicate numbers) Summary: I want to select rows where the ROAD_ID, YEAR_, STATUS, FROM_MEASURES, and TO_MEASURES are duplicated. In the case of FROM_MEASURES and TO_MEASURES, I want to use a 5 metre tolerance. For example, these TO_MEASURES would be considered duplicates: 200.6, 199.3, and 201. PROJ_ID ROAD_ID YEAR_ STATUS FROM_MEASURE TO_MEASURE ---------- ---------- ---------- -------- ------------ ---------- 100 1 2022 APPROVED null 100.1 --duplicates (other than PROJ_ID); null is to be treated as zero 101 1 2022 APPROVED 0 100.1 102 1 2022 APPROVED 0 200.6 --duplicates: TO_MEASURES are approximately the same (within a 5 metre tolerance) 103 1 2022 APPROVED 0 199.3 104 1 2022 APPROVED 0 201 105 2 2023 PROPOSED 0 50 --not duplicates: FROM_MEASURES are different and TO_MEASURES are different 106 2 2023 PROPOSED 75 100 107 3 2024 DEFERRED 0 100 --not duplicates: YEARS are different and TO_MEASURES are different 108 3 2025 DEFERRED 0 110 109 4 2026 PROPOSED 0 null --not duplicates: STATUSES are different 110 4 2026 DEFERRED 0 null Solution: select * from road_projects rp where exists ( select null from road_projects rp2 where rp2.proj_id != rp.proj_id and rp2.road_id = rp.road_id and rp2.year_ = rp.year_ and rp2.status = rp.status and abs(coalesce(rp2.from_measure, 0) - coalesce(rp.from_measure, 0)) < 5 and abs(coalesce(rp2.to_measure, 0) - coalesce(rp.to_measure, 0)) < 5 ) order by proj_id   52D7861C-F33E-4217-B91A-D3703D4FB8D1.jpeg fiddle   ... View more

In Catalog: It would be helpful if we could filter/show/hide enterprise geodatabase connection items (FCs, tables, views, relationship classes) by owner. For example, if there are items from several owners (ROADS, WATER_RES, WATER), let me only see items from WATER. My connection is OS Authentication (items from lots of owners), not a DB/owner-based connection (only one owner). Oracle 10.7.1 EGDB ... View more

It would be helpful if we could view related records right in the attribute table underneath a parent record: Bud_1-1661377343876.png I'm aware that there are similar mechanisms in the attribute window/identify window. And I'm aware that it's possible to show related records via a separate/stacked section in the attribute table. Those mechanisms work, but they have limitations. It would be better if we could explore parent/child records all within a single expanded tree right in the attribute table. Related: Subdatasheets in MS Access   ... View more

When creating a dynamic/in-map join, it would be helpful if we could specify the join clause using SQL. For example, join on multiple fields: Instead of joining only on EVENT_ID=EVENT_ID, join on multiple fields: EVENT_ID=EVENT_ID AND YEAR=YEAR. Bud_1-1661376632521.png Bud_0-1661376474497.png   ... View more

It would be helpful if there were OOTB functionality in Pro that would track all edits in a separate table (including tracking deleted rows). For example, a rough idea might be: Bud_0-1660138227726.png (would need further consideration / open to ideas) Not the same thing as editor tracking fields (only tracks creation date/editor and last editor/date; doesn't track deletes). We don't want to use archiving. We don't want to store all edits in the master table. That makes things messy when it comes to SQL queries...we don't want to deal with the clutter of having old edit info in the master table. We're aware that this kind of thing can be done using attribute rules or with custom database functionality. But we don't want to write custom code for this. It would be better if we could use OOTB functionality. This seems like a common requirement. Lots of people seem to write attribute rules for this kind of thing...to track transactions in a separate table. Ideally, we wouldn't all be writing the same custom functionality. Could it be offered OOTB instead?   ... View more