Latest Contributions by KendraHopper2

‎03-12-2019

Just an update, the final decision was to use the Repeat group to add the new Status with a timestamp as a related record to the incident. The aesthetics came secondary to the functionality to track the sequence of Status changes. There is a "CurrentStatus" field in the the Parent Record that is updated by the related "New Status" using the Calculation "jr:choice-name(${NewStatus}, '${NewStatus}')". This allows for display of the most recent status on the form, but also for mapping symbology of the point. The use of the "bind::esri:parameters" "query orderBy="IncidentDateTime DESC"" will be useful when it is working again (at 3.2.196 this functionality does not presently work, but is on the list to be fixed). This will ensure that the most recent Status will be first on display on the form within the list repeats. Once this record has been submitted, it cannot be updated. If the status of the incident changes, a new record is made.

‎02-22-2019

Hi Brandon, Just double checking that at v3.2.265 the " orderBy parameter is not currently working for editing repeats in the inbox" is still not working, and that it's not syntax on my end? Thanks! Jen

‎02-14-2019

Hi there, There is a requirement to timestamp an "incident's" status change in order to keep track of the the length of time it took to resolve the incident from start to finish. Many different incidents may occur at the same time, and can remain 'open' for varying lengths of time. What is a recommended way of setting up the form to capture the timstamped sequence, and not overwrite existing record data? Instead of creating a new survey point, the thought is to leverage the "Edit and resend survey" functionality via the Sent Inbox. Already tried: - Repeats: The begin/end repeat looks clumsy and is not intuitive for displaying the current status and changing that status to the next step. Maybe there are some tricks with the use of appearance and relevant that could make this more user friendly? - Unique fields for each status timestamp: unfortunately the Update overwrites existing values with nulls. New status, has a timestamp of New_datetime, Resolved has a timestamp of Resolved_datetime. If the Newdatetime value isn't carried through, it is updated with a null value when the resolved status is chosen. Is there a way to carry the values through? This is very challenging to describe! But I would be greatly appreciative for any suggestions. Thanks!

‎02-08-2019

Could it be possible that the attached python script is breaking the link between parent-child related records? Is it possible that the arcpy.da.insertcursor does not play well with related tables in a geometric network? It would be a great help if you had the time to peer-review the code in the attached arcpy_Update.txt. The GIS tables are related to each other via Relationship Classes within a Geometric Network. It was noticed that the number of related records returned using the "Related Tables" selection tools is different than if a "Select By Attributes" query was used. This is an open ticket with esri, however, the thought is that it is the script that is causing the issue, and scripting is out of support scope. Should a "Reconcile/Compres/Rebuild Indexes/Analyze" be included after the arcpy.da.insertcursor before the Update and Delete records? As with any code, this has been pieced together from many different, and valuable sources with a special thank you to Richard Fairhurst‌'s blog post "Turbo Charging Data Manipulation with Python Cursors and Dictionaries": this script could not exist without the contents, comments and leads from that post. My thanks in advance!

‎02-08-2019

Of course! Great advice. Thank you!

‎02-08-2019

Hello! There's no question that this is my #1 most visited post. It's provided a wealth of information and feedback that has enabled me to automate an essential business process. So, a big thank you to all who have constructively contributed! I'm wondering if anyone would be willing to peer-review the python script that I have put together. As with many GIS shops, I'm the only one with the esri/python knowledge, and it would be fantastic to have a second set of eyes to look for efficiencies (and yes, I'll hesitate to admit, potential errors...). The script is running like a charm, updating, adding and deleting records of a related table within a geometric network. Unfortunately, I have recently noticed that there could be some corruption to the related table indexing, or there is something inherently broken with the "Related Table" tool. I have a support ticket open with esri, but they do not support scripting. What is the best platform for peer-review of scripting? I don't want to dilute this post since it is by far the most concentrated knowledge for the use of these cursors that I am aware of. Do you have any suggestions as to how/where I could get a second option on my code? Thanks in advance, Jen

‎01-28-2019

I'm wondering if this is related (no pun intended! ) to this bug: BUG-000116614 : When more than 99 records are selected in the feature class involved in a relationship class, the related table returns an incorrect selection result.

Online Status	Offline
Date Last Visited	‎11-11-2020 02:25 AM

My Ideas

Latest Contributions by KendraHopper2

Re: Updating an existing survey record status with a timestamp - what's the best survey structure?

Re: Talk Like a Pirate Release (2.4)

Updating an existing survey record status with a timestamp - what's the best survey structure?

Arcpy.da.insertcursor, Update, Delete and the Related Table Indexing of a Geometric Network

Re: Turbo Charging Data Manipulation with Python Cursors and Dictionaries

Re: Turbo Charging Data Manipulation with Python Cursors and Dictionaries

Re: Can't select all related features in attribute table