Refresh a Table View after Append_management

[RichardFairhurst]

I am trying to use the Append_management tool in a Python script tool where a table view in ArcMap is the output.  The append works, but if the table view is open the appended records won't appear and the record count won't change until I manually close the table view and reopen it.  Using arcpy.RefreshActiveView() and reloading the table cache manually does nothing, only manually closing and reopening the table view works.  Is there any way to make Python get the table view to refresh without a user having to manually close and reopen the table view?  The behavior is the same if I run Append_management directly in ArcMap outside of my script tool.

Is this a bug in the Append_management tool that needs to be fixed or do I need to add an Idea to the Ideas website requesting that a refresh subroutine be added to the tool or arcpy.RefreshActiveView() that will work when a table view is the output?  Is writing my own Append_management routine using a cursor my only option?  Will a Python Insertcursor update the table view, or do I need to use a .Net Insertcursor and refresh options to make this work?

This is all because ESRI is stupidly refusing to even consider the idea of making a Copy/Paste Rows option available for a StandAlone table.  I resent having to do their work for them with my own tool in the first place, but lame behavioral glitches like this make it that much more frustrating.

[LT]

I haven't tried it, but you could try making the table view a derived output (set the script tool parameter type and direction properties) and then using arcpy.setParameterAsText(theTableParameterIndex, theTableVariableName) at the end of your script.  I believe, that I have found that this does update existing feature class tables when I add a field (in a script tool) to something that's already open.

[T__WayneWhitley]

Richard, I don't know if you've seen this promising post by Duncan Hornby:
http://forums.arcgis.com/threads/5690-Update-View-of-Attribute-Table-in-ArcMap-(Reload-Cache)#2

Anyway, I haven't had time to check it out although I've been itching to....looks like it gets a handle on all the open tables and reloads the cache.  Surprised no one has upvoted his post yet.  With a knowledge of .NET add-ins, I suppose you 'hinge' a listener to execute for an on-change event -- I'm just not certain how you'd listen for changes in the map (like an Append), but guess you could also simply make an extra button, but then again you already have a 'reload cache' button in the table window.


Wayne

[RichardFairhurst]

I haven't tried it, but you could try making the table view a derived output (set the script tool parameter type and direction properties) and then using arcpy.setParameterAsText(theTableParameterIndex, theTableVariableName) at the end of your script. I believe, that I have found that this does update existing feature class tables when I add a field (in a script tool) to something that's already open.

Thanks for the suggestion. I added the derived parameter to the tool as an output. The code threw an error when I used arcpy.setParameterAsText, but ran when I used arcpy.SetParameterAsText. However, the result was the same as my original tool. If the Table View was closed it showed the appended records and updated record count when I opened the table view. However, the Table View did not refresh after the tool ran if it was open while the tool ran. It also did not refresh when I manually reloaded the table cache. I had to close and reopen it to make it show the appended records and refresh the record count.

Here is the full code I tried, where parameter index 3 is the derived output parameter:

import arcpy

tblCopyRecords = arcpy.GetParameterAsText(0)
if not arcpy.Exists(tblCopyRecords):
    arcpy.AddMessage("Invalid Input table provided: " + tblCopyRecords)
    
xTimes = int(arcpy.GetParameterAsText(1))

tblPasteRecords = arcpy.GetParameterAsText(2)

if tblPasteRecords == '':
    tblPasteRecords = tblCopyRecords

if not arcpy.Exists(tblPasteRecords):
    arcpy.AddMessage("Invalid Output table provided: " + tblPasteRecords)
    
arcpy.CopyRows_management(tblCopyRecords, "in_memory/tblScratch")
for i in range(0, xTimes):
    arcpy.Append_management("in_memory/tblScratch", tblPasteRecords, "NO_TEST")

tblOutput = arcpy.SetParameterAsText(3, tblPasteRecords)

arcpy.RefreshActiveView()

It seemed like a reasonable approach, unfortunately it does not appear to work.

[RichardFairhurst]

Richard, I don't know if you've seen this promising post by Duncan Hornby:
http://forums.arcgis.com/threads/5690-Update-View-of-Attribute-Table-in-ArcMap-(Reload-Cache)#2

Anyway, I haven't had time to check it out although I've been itching to....looks like it gets a handle on all the open tables and reloads the cache.  Surprised no one has upvoted his post yet.  With a knowledge of .NET add-ins, I suppose you 'hinge' a listener to execute for an on-change event -- I'm just not certain how you'd listen for changes in the map (like an Append), but guess you could also simply make an extra button, but then again you already have a 'reload cache' button in the table window.


Wayne

Thanks for this suggestion also.  I tried running the code where I just refresh every open table view rather than a specific table view.  I ran the Python code that used the Append_management tool and left the table view open.  Then I ran Duncan's code.  The open table view did not show the appended records or update the record count after Duncan's code successfully ran.  I expected this result, since the Reload Cache button also does not work when I press it manuallly.  I had to manually close and reopen the table view.  If there is an ArcObjects way to close and reopen the table view I could try that, but it appears as long as the table view is open it will not reflect the output of the Append_management tool.

This seems like a bug.  If ESRI is going to let me process a tool on an open table view, I ought to have some method of refreshing the table view after the tool runs without requiring a user to manually close and reopen the table view every time.

[RichardFairhurst]

I had similar issues with .Net code I wrote that splits LR event records with a mouse click.  In that case I ran a cursor against the underlying source table for the event to insert the duplicated records needed to accomplish the split.  The only way I got it show anything in the LR Event table was to run a select query after the records were inserted.  That worked to make the records appear.  However, the actual split would still not be reflected in the actual events displayed on my map screen until I manually changed or recopied over at least one attribute manually in each record.

At least this tool showed me something had changed in the event table without me having to close and reopen it, even if I had to manually touch every record to fully complete the process.  I believe that if I ran the Field Calculator to overwrite a field with its existing value I could to force the completion of the event update, but I have not tried that yet.

ESRI's response to this behavior and my request for a way to fully refresh the event table was that they do not support editing event tables and that they had added a warning when the editor is started to indicate that event tables are not editable, even though they are editable.  They said I had to convert the events to features to have my edits work, but that defeats my purpose in using event tables in the first place and confirms my view that they think Standalone tables aren't really worth supporting.

They implied, without actually coming out and saying it, that at some release in the future they will actually fully cripple all event table editing.  I suppose they think their warning will wean users from doing event table edits, but that certainly is not the case for me.  This is insane and going opposite of what any user should want.

If ESRI actually fully prevents editing of XY and LR event tables at all at some point I hope user complaints go through the roof.  If you care about Standalone tables please make your voice heard.  Standalone table users need to make ESRI listen to and respect our needs now or we risk losing any functionality for Standalone tables worth having in future downgrades.

[LT]

Sorry about the s vs S typo.  I don't use that command very often (I prefer sys.argv).  But it's too bad that didn't work.   I'll throw in one more simplistic suggestion.  You could try to get the modified version to open in another instance of Arc (Map? Catalog?). 

Take the SetParameterAsText stuff out and put in an os.startfile(theFileofInterest)

This command launches an instance of the default program associated with that file.  I don't think I've tried it with files that are already open in something else. Also, I haven't worked with table views, so I don't know what the default application is.

[RichardFairhurst]

I really don't want to open a new instance of ArcMap even if that would work, since I want the current map to be the output target.  I would much prefer to force the table view to close and then reopen it.  It would even be acceptable if I could just close the table view so that the user knew something had happened after the tool ran and had to reopen the table view so that the appended records and updated record count would show up.  Is there any Python code or .Net code out there to do this?

I managed to get my .Net LR Line Event Split tool to completely update the table view and the events on the map screen by adding a Field Calculator subroutine at the end of my code.  I just had to calculate one of the event table fields to the existing value the field already contained using the code provided in this post with the modifications mentioned by the user that tested it out..  So at least I have had some success on a related issue that had me stuck for weeks without a solution before and that ESRI would not help me overcome.

Unfortunately adding a Field Calculator process at the end of my Python code did not cause the table to update in response to the Append_management tool.  I will call it in and report it as a bug to ESRI on Monday.

[LT]

One more suggestion... In your script tool, try setting up an input parameter that you set to your existing table view name.  Then for the derived output table view, set the 'Obtained From' property to the input table view parameter.