Latest Contributions by RichardFairhurst

Join is your only option for symbolizing based on a field in a related table.  The only other option is to join the related table and calculate the ID into a field stored on the target feature class so you can symbolize directly from the feature class.  If the relationship is a one-to-many or many-to-many relationship then you could export the join to a new feature class to create a feature for each record in the related table.  Symbology cannot be set up to use a relate. ... View more

To do a full update there are 3 separate processes.  Update records, which occurs as you iterate through the updateCursor records and find a key match in the csv dictionary.  Delete records (optional), which occurs as you iterate through the updateCursor records and do not find a key match in the csv dictionary.  Update and Delete can be done as you do a single pass on all of the updateCursor records.  Finally, Insert records, which I usually approach by first creating a dictionary of the updateCursor records after every record has been updated and deleted.  Then I iterate through the csv file or csv dictionary records and if it is not in the updateCursor record dictionary, I insert that records using an InsertCursor into the FC being updated. If the FC you are updating is empty and all you are doing is adding records, you need to use an insertCursor, not an updateCursor. ... View more

You have opened an UpdateCursor and looped through the records which is applying a lock to your data before you do the calculation and have not closed the cursor.  You need to delete the row variable at the end of the statements inside the for loop and delete the rows variable outside of the for loop after the for loop is completed.  You also should have used the da UpateCursor, which performs much quicker and includes a With syntax that closes the cursor automatically once the cursor has been read or statements are executed at the same indent level as the With declaration.  If this was my code, I would restructure the code to do all of the AddField operations before doing any updateCursor or Field Calculation operations to be safe. ... View more

Glad it is working now and that both tables are now combined in the final output. The dictionary created in Line 16 was being changed after you ran Lines 19-21.  The keys were the same, but the values associated with the keys are very different.  In Line 16 the value associated with each dictionary key is a list containing values from Field B, Field C, Field D and Field E.  After running Line 16, if you use the code table_a_data[row[0]]‍‍‍‍ the dictionary will return the list of field values, not a single field value.  In order to get the value from just Field B from the list, a second set of brackets needs to be added with the index number of the value for Field B in the list (i.e. [0]).  So, to directly call the value of Field B from the dictionary in one line of code you need to use table_a_data[row[0]]‍[0]‍‍ The list of field values associated with each dictionary key in Line 16 no longer existed after running lines 19-21.  Lines 19-21 was changing the value associated with each dictionary key to being the value of Field B only.  Therefore, after you ran Lines 19-21 you just needed to return the value associated with the dictionary key to get the value of Field B directly. You could have used two dictionaries to do the comparison in Lines 40-50, but you would need to use the dictionary created in Line 16, not the dictionary as modified by Lines 19-21.  Instead of doing a for loop of the rows of the   Table_A_Cursor, you would do a for loop of the keys of the table_a_data dictionary.  Instead of assigning values to each field from row2 returned by the cursor, you would have assigned values to each field using the appropriate list index on the list returned from the table_a_data dictionary for each unmatched key, i.e. for key in table_a_dict:     if not key in FC_B_data:         insert = rows.newRow()         insert.setValue("field D", table_a_dict[key][2])         insert.setValue("field C", table_a_dict[key][1])         insert.setValue("field B", table_a_dict[key][0])         insert.setValue("field E", table_a_dict[key][3])         insert.setValue("field F", 'NOT IN GIS:DELETE FROM Table_A?')         rows.insertRow(insert) ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   ... View more

I think the real error is occurring because you are trying to create a newRow object using the SearchCursor row2 on line 42, which won't work.  Line 42 needs to use the InsertCursor rows to create a newRow:         insert = rows.newRow()‍‍ # Line 42‍‍‍‍‍‍‍ ... View more

After looking at your code more carefully I withdraw my original comment. Where are you getting errors with your current code? Line 19 through 21 and Lines 33 through 35 seem unnecessary, since you have already read all records from those tables into the dictionaries you created on lines 15 and 16.  If you removed those unnecessary lines you could do the comparison on line 23 using this code:     if abs(row [1]-table_a_data[row[0]][0])>Tolerance: ... View more

First, since you mention that you are using SetValue method, it sounds like you are using the outdated cursors that predate the da cursors, since SetValue is not necessary with da cursors.  If you are, I highly recommend using only da cursors. Without seeing the code you have attempted, it is a little difficult to understand the logic you are attempting.  I do know that dealing with InsertCursors can be tricky, since they can cause failures if they are initialized inside of a loop or if the schemas of the two tables you are comparing are different and you did not take care to standardize the field order and number of values expected by the receiving table. Anyway, I know it is possible to do comparisons of two data sources using the dictionary approach and process attribute or geometry updates to records that match on a key field set, delete records from a child that are no longer in the master and insert records into a child that have been added to the master since the last update.  I have a variety of scripts that do these kinds of synchronization operations in various combinations using different output options.  In my experience, problems with doing synchronizations most often arise when the code gets overly complicated and attempts to blend everything together into a single embedded loop process rather than breaking it down into separate discrete steps. ... View more

The typical way I have dealt with section, township and range polygon edges is to start with a polygon layer with all section polygons that are hopefully topologically correct so that gaps and overlaps are avoided.  Then I use the Polygon to Line tool with the Identify Neighbor option checked.  I then add fields to the lines for the Left and Right Section, Township and Range and Line_Side_Type.  I join the LEFT_FID field of the Lines to the polygon ObjectID and calculate all of the left fields I created for Section, Township and Range.  Then I break the join.  Then I join the RIGHT_FID field of the Lines to the polygon ObjectID and calculate all of the right fields I created for Section, Township and Range.  Then I break the join. Now I can select for logical relationships of sections to determine what the side types are.  For example, the LEFT_LINE_SIDE_TYPE for the polygon is BOTTOM and the RIGHT_LINE_SIDE_TYPE for the polygon is TOP because the line is pointing right which can be found for normal sections using the following query: (LEFT_SECTION = 1 AND RIGHT_SECTION = 12) OR (LEFT_SECTION = 2 AND RIGHT_SECTION = 11) OR (LEFT_SECTION = 3 AND RIGHT_SECTION = 10) OR (LEFT_SECTION = 4 AND RIGHT_SECTION = 9) OR (LEFT_SECTION = 5 AND RIGHT_SECTION = 😎 OR (LEFT_SECTION = 6 AND RIGHT_SECTION = 7) OR (LEFT_SECTION = 7 AND RIGHT_SECTION = 18) OR (LEFT_SECTION = 8 AND RIGHT_SECTION = 17) OR (LEFT_SECTION = 9 AND RIGHT_SECTION = 16) OR (LEFT_SECTION = 10 AND RIGHT_SECTION = 15) OR (LEFT_SECTION = 11 AND RIGHT_SECTION = 14) OR (LEFT_SECTION = 12 AND RIGHT_SECTION = 13) OR (LEFT_SECTION = 13 AND RIGHT_SECTION = 24) OR (LEFT_SECTION = 14 AND RIGHT_SECTION = 23) OR (LEFT_SECTION = 15 AND RIGHT_SECTION = 22) OR (LEFT_SECTION = 16 AND RIGHT_SECTION = 21) OR (LEFT_SECTION = 17 AND RIGHT_SECTION = 20) OR (LEFT_SECTION = 18 AND RIGHT_SECTION = 19) OR (LEFT_SECTION = 19 AND RIGHT_SECTION = 30) OR (LEFT_SECTION = 20 AND RIGHT_SECTION = 29) OR (LEFT_SECTION = 21 AND RIGHT_SECTION = 28) OR (LEFT_SECTION = 22 AND RIGHT_SECTION = 27) OR (LEFT_SECTION = 23 AND RIGHT_SECTION = 26) OR (LEFT_SECTION = 24 AND RIGHT_SECTION = 25) OR (LEFT_SECTION = 25 AND RIGHT_SECTION = 30) OR (LEFT_SECTION = 26 AND RIGHT_SECTION = 35) OR (LEFT_SECTION = 27 AND RIGHT_SECTION = 34) OR (LEFT_SECTION = 28 AND RIGHT_SECTION = 33) OR (LEFT_SECTION = 29 AND RIGHT_SECTION = 32) OR (LEFT_SECTION = 30 AND RIGHT_SECTION = 31) OR (LEFT_SECTION = 31 AND RIGHT_SECTION = 6) OR (LEFT_SECTION = 32 AND RIGHT_SECTION = 5) OR (LEFT_SECTION = 33 AND RIGHT_SECTION = 4) OR (LEFT_SECTION = 34 AND RIGHT_SECTION = 3) OR (LEFT_SECTION = 35 AND RIGHT_SECTION = 2) OR (LEFT_SECTION = 36 AND RIGHT_SECTION = 1) The LEFT_LINE_SIDE_TYPE for the polygon is TOP and  the RIGHT_LINE_SIDE_TYPE for the polygon is BOTTOM because the line is pointing left which can be found for normal sections using the following query: (RIGHT_SECTION = 1 AND LEFT_SECTION = 12) OR (RIGHT_SECTION = 2 AND LEFT_SECTION = 11) OR (RIGHT_SECTION = 3 AND LEFT_SECTION = 10) OR (RIGHT_SECTION = 4 AND LEFT_SECTION = 9) OR (RIGHT_SECTION = 5 AND LEFT_SECTION = 😎 OR (RIGHT_SECTION = 6 AND LEFT_SECTION = 7) OR (RIGHT_SECTION = 7 AND LEFT_SECTION = 18) OR (RIGHT_SECTION = 8 AND LEFT_SECTION = 17) OR (RIGHT_SECTION = 9 AND LEFT_SECTION = 16) OR (RIGHT_SECTION = 10 AND LEFT_SECTION = 15) OR (RIGHT_SECTION = 11 AND LEFT_SECTION = 14) OR (RIGHT_SECTION = 12 AND LEFT_SECTION = 13) OR (RIGHT_SECTION = 13 AND LEFT_SECTION = 24) OR (RIGHT_SECTION = 14 AND LEFT_SECTION = 23) OR (RIGHT_SECTION = 15 AND LEFT_SECTION = 22) OR (RIGHT_SECTION = 16 AND LEFT_SECTION = 21) OR (RIGHT_SECTION = 17 AND LEFT_SECTION = 20) OR (RIGHT_SECTION = 18 AND LEFT_SECTION = 19) OR (RIGHT_SECTION = 19 AND LEFT_SECTION = 30) OR (RIGHT_SECTION = 20 AND LEFT_SECTION = 29) OR (RIGHT_SECTION = 21 AND LEFT_SECTION = 28) OR (RIGHT_SECTION = 22 AND LEFT_SECTION = 27) OR (RIGHT_SECTION = 23 AND LEFT_SECTION = 26) OR (RIGHT_SECTION = 24 AND LEFT_SECTION = 25) OR (RIGHT_SECTION = 25 AND LEFT_SECTION = 30) OR (RIGHT_SECTION = 26 AND LEFT_SECTION = 35) OR (RIGHT_SECTION = 27 AND LEFT_SECTION = 34) OR (RIGHT_SECTION = 28 AND LEFT_SECTION = 33) OR (RIGHT_SECTION = 29 AND LEFT_SECTION = 32) OR (RIGHT_SECTION = 30 AND LEFT_SECTION = 31) OR (RIGHT_SECTION = 31 AND LEFT_SECTION = 6) OR (RIGHT_SECTION = 32 AND LEFT_SECTION = 5) OR (RIGHT_SECTION = 33 AND LEFT_SECTION = 4) OR (RIGHT_SECTION = 34 AND LEFT_SECTION = 3) OR (RIGHT_SECTION = 35 AND LEFT_SECTION = 2) OR (RIGHT_SECTION = 36 AND LEFT_SECTION = 1) The LEFT_LINE_SIDE_TYPE for the polygon is LEFT and the RIGHT_LINE_SIDE_TYPE for the polygon is RIGHT when the line is pointing down which can be found for normal sections using the following query. (LEFT_SECTION = 1 AND RIGHT_SECTION = 2) OR (LEFT_SECTION = 2 AND RIGHT_SECTION = 3) OR (LEFT_SECTION = 3 AND RIGHT_SECTION = 4) OR (LEFT_SECTION = 4 AND RIGHT_SECTION = 5) OR (LEFT_SECTION = 5 AND RIGHT_SECTION = 6) OR (LEFT_SECTION = 6 AND RIGHT_SECTION = 1) OR (LEFT_SECTION = 8 AND RIGHT_SECTION = 7) OR (LEFT_SECTION = 9 AND RIGHT_SECTION = 😎 OR (LEFT_SECTION = 10 AND RIGHT_SECTION = 9) OR (LEFT_SECTION = 11 AND RIGHT_SECTION = 10) OR (LEFT_SECTION = 12 AND RIGHT_SECTION = 11) OR (LEFT_SECTION = 7 AND RIGHT_SECTION = 12) OR (LEFT_SECTION = 13 AND RIGHT_SECTION = 14) OR (LEFT_SECTION = 14 AND RIGHT_SECTION = 15) OR (LEFT_SECTION = 15 AND RIGHT_SECTION = 16) OR (LEFT_SECTION = 16 AND RIGHT_SECTION = 17) OR (LEFT_SECTION = 17 AND RIGHT_SECTION = 18) OR (LEFT_SECTION = 18 AND RIGHT_SECTION = 13) OR (LEFT_SECTION = 20 AND RIGHT_SECTION = 19) OR (LEFT_SECTION = 21 AND RIGHT_SECTION = 20) OR (LEFT_SECTION = 22 AND RIGHT_SECTION = 21) OR (LEFT_SECTION = 23 AND RIGHT_SECTION = 22) OR (LEFT_SECTION = 24 AND RIGHT_SECTION = 23) OR (LEFT_SECTION = 19 AND RIGHT_SECTION = 24) OR (LEFT_SECTION = 25 AND RIGHT_SECTION = 26) OR (LEFT_SECTION = 26 AND RIGHT_SECTION = 27) OR (LEFT_SECTION = 27 AND RIGHT_SECTION = 28) OR (LEFT_SECTION = 28 AND RIGHT_SECTION = 29) OR (LEFT_SECTION = 29 AND RIGHT_SECTION = 30) OR (LEFT_SECTION = 30 AND RIGHT_SECTION = 15) OR (LEFT_SECTION = 32 AND RIGHT_SECTION = 31) OR (LEFT_SECTION = 33 AND RIGHT_SECTION = 32) OR (LEFT_SECTION = 34 AND RIGHT_SECTION = 33) OR (LEFT_SECTION = 35 AND RIGHT_SECTION = 34) OR (LEFT_SECTION = 36 AND RIGHT_SECTION = 35) OR (LEFT_SECTION = 31 AND RIGHT_SECTION = 36) The LEFT_LINE_SIDE_TYPE for the polygon is RIGHT and the RIGHT_LINE_SIDE_TYPE for the polygon is LEFT when the line is pointing up which can be found for normal sections using the following query. (RIGHT_SECTION = 1 AND LEFT_SECTION = 2) OR (RIGHT_SECTION = 2 AND LEFT_SECTION = 3) OR (RIGHT_SECTION = 3 AND LEFT_SECTION = 4) OR (RIGHT_SECTION = 4 AND LEFT_SECTION = 5) OR (RIGHT_SECTION = 5 AND LEFT_SECTION = 6) OR (RIGHT_SECTION = 6 AND LEFT_SECTION = 1) OR (RIGHT_SECTION = 8 AND LEFT_SECTION = 7) OR (RIGHT_SECTION = 9 AND LEFT_SECTION = 😎 OR (RIGHT_SECTION = 10 AND LEFT_SECTION = 9) OR (RIGHT_SECTION = 11 AND LEFT_SECTION = 10) OR (RIGHT_SECTION = 12 AND LEFT_SECTION = 11) OR (RIGHT_SECTION = 7 AND LEFT_SECTION = 12) OR (RIGHT_SECTION = 13 AND LEFT_SECTION = 14) OR (RIGHT_SECTION = 14 AND LEFT_SECTION = 15) OR (RIGHT_SECTION = 15 AND LEFT_SECTION = 16) OR (RIGHT_SECTION = 16 AND LEFT_SECTION = 17) OR (RIGHT_SECTION = 17 AND LEFT_SECTION = 18) OR (RIGHT_SECTION = 18 AND LEFT_SECTION = 13) OR (RIGHT_SECTION = 20 AND LEFT_SECTION = 19) OR (RIGHT_SECTION = 21 AND LEFT_SECTION = 20) OR (RIGHT_SECTION = 22 AND LEFT_SECTION = 21) OR (RIGHT_SECTION = 23 AND LEFT_SECTION = 22) OR (RIGHT_SECTION = 24 AND LEFT_SECTION = 23) OR (RIGHT_SECTION = 19 AND LEFT_SECTION = 24) OR (RIGHT_SECTION = 25 AND LEFT_SECTION = 26) OR (RIGHT_SECTION = 26 AND LEFT_SECTION = 27) OR (RIGHT_SECTION = 27 AND LEFT_SECTION = 28) OR (RIGHT_SECTION = 28 AND LEFT_SECTION = 29) OR (RIGHT_SECTION = 29 AND LEFT_SECTION = 30) OR (RIGHT_SECTION = 30 AND LEFT_SECTION = 15) OR (RIGHT_SECTION = 32 AND LEFT_SECTION = 31) OR (RIGHT_SECTION = 33 AND LEFT_SECTION = 32) OR (RIGHT_SECTION = 34 AND LEFT_SECTION = 33) OR (RIGHT_SECTION = 35 AND LEFT_SECTION = 34) OR (RIGHT_SECTION = 36 AND LEFT_SECTION = 35) OR (RIGHT_SECTION = 31 AND LEFT_SECTION = 36) All other lines are either on the outer boundaries of all sections, at offsets of adjoining townships or are portions of non-standard sections that do not align with the normal section grid pattern. You can use the Intersect Tool or Spatial Join tool on your points with these lines to assign them with the side types of the polygons that touch them.  With some relatively simple manipulations of record selections, field calculations and the append tool you could create the set of lines that cover each side of each section separately and use them for the intersect. ... View more

If you are trying to use python to display labels on a map that get data from a related table in a one-to-many or many-to-many relationship then take a look at my Creating Labels with Related Table Data Blog. ... View more

You need to make the updateFieldsList = ["BSB_Text", ?????] line read: updateFieldsList = ["BSB_Text", "Value"] I am backing up to code that I you did not show completely. Where do the variables ABN and weightfldval get set and what values do they have? arcpy.AddField_management(ABN, weightfldval, "DOUBLE", "", "", "", "", "NULLABLE", "NON_REQUIRED", "") I do not see where you set the FacilitiesOutput variable value.  I believe it should match the same path and FC name as the sourceFC = r"C:\xxx\xxx\Scratch_Workspce.gdb\FacilitiesOutput" arcpy.management.CopyFeatures(FacilitiesSubLayer,FacilitiesOutput) Also I hope you removed the erroneous space character that comes after ABN in this line of code: updateFC = r"C:\xxx\xxx\Scratch_Workspce.gdb\ABN " should be updateFC = r"C:\xxx\xxx\Scratch_Workspce.gdb\ABN" If your code still does not work try running this code using hardcoded values and get it to work.  Then you can modify all of the processes that set your input FCs, layers, etc based on variables.  If the base code below works and then breaks as you modify the way inputs and outputs are determined at runtime, then you will know the problem is not in this part of the code. import arcpy    # hardcode the path to the correct gdb and FC sourceFC = r"C:\xxx\xxx\Scratch_Workspce.gdb\FacilitiesOutput"    sourceFieldsList = ["Name", "DemandWeight"]    # Use list comprehension to build a dictionary from a da SearchCursor  valueDict = {r[0]:r[1] for r in arcpy.da.SearchCursor(sourceFC, sourceFieldsList)}    # hardcode the path to the correct gdb and FC updateFC = r"C:\xxx\xxx\Scratch_Workspce.gdb\ABN"    updateFieldsList = ["BSB_Text", "Value"]    with arcpy.da.UpdateCursor(updateFC, updateFieldsList) as updateRows:      for updateRow in updateRows:          # store the Join value of the row being updated in a keyValue variable          keyValue = updateRow[0]          # verify that the keyValue is in the Dictionary          if keyValue in valueDict:               # transfer the value stored under the keyValue from the dictionary to the updated field.              updateRow[1] = valueDict[keyValue]              updateRows.updateRow(updateRow)    del valueDict‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ... View more

Please complete what you actually used for this line of code for the output field name: updateFieldsList = ["BSB_Text", ?????] The output field would be wahtever field you used in place of ????? Also, your dictionary indicates the values associated with the keys are not within a tuple, so it does not seem you are using your original code.  Anyway, you would have to make sure the line populating the output field is: updateRow[1] = valueDict[keyValue] ... View more

Why do you think the code is not working?  The DemandWeight values all appear to be 0.0 in your sample, so if that is what you are seeing for keys like u'3923', u'3920', u'5259', u'4023', u'6725', etc., the code worked.  Show what you expect the value to be for those keys.  I suspect you are not populating the DemainWeight during any pass of your code, like you may have done in your Model.  Also, the code you showed does not use a real output field name (?????), so I don't know if that is an issue.  If a join succeeded, that indicates that both tables have a text field value that you are matching and would both contain unicode keys like u'2003',u'2006',u'2010',u'2013', not numeric values like 2003, 2006, 2010, 2013.  Anyway, without the ability to see the actual table key value pairs the dictionary was told to read or the output table, it is impossible to identify where the mismatch is between your code and what you actually want the code to do. ... View more

Warren: Are you sure that the values in the Name field in the FacilitiesOutput FC exactly match the values in the BSB_Text field in the ABN FC?  The code will only transfer data where there is an exact match on the values in those fields.  Also, since you are only using two fields as a key and value to create the dictionary, you do not need to load the value portion into a tuple and can just return the value of the dictionary directly without indexing. valueDict = {r[0]:r[1] for r in arcpy.da.SearchCursor(sourceFC, sourceFieldsList)} ...  updateRow[1] = valueDict[keyValue] ... View more

If the only changes ever made to your Source FC were the addition of new UNITs that completely did not exist in the Dissolve feature set or the complete removal of UNITs from the Source FC that need to be deleted from the Dissolve FC, then you can write an efficient script to detect those changes just by comparing the UNIT values in the two FCs.  But everyone does edits that trigger more than just additions and deletion of features in a derivative FC.  They do edits that trigger partial changes to features that already exist in their derivative FC.   I have never seen a dataset with more than 1000 features that only makes edits in the Source FC that would create and destroy derivative features and never cause any existing derivative features to be partially changed. Any edits that cause partial changes in already existing derivative features cannot be detected by comparing a source FC with a derivative FC without completely redoing the operation that created the derivative.  You can only detect those changes at a tabular level if you have a changes table that tracks each edit as it happens, like versioning does in SDE, or if you have a copy of the version of the Source FC that existed before any edits were made.  The only other approach would be to use Attribute Assistant to date stamp all geometry and attribute changes in a field in the Source FC as edits are being made and to also have a date field in the Dissolve FC showing the last time the dissolved features were edited.  Then you could write a script to compare the UNIT values and the dates to determine the set of Source FC features that needed to be redissolved.  However, this approach would still not detect the complete removal of a feature in the Source FC.  To detect that your Dissolve FC would have to also include a Frequency/Source Feature Count field so that you could compare the counts of features in the Source FC to the count of features that made up the last dissolve for a given UNIT. ... View more