Private Tables from SQL Query << Run Background, New Data View, table list not updating?

[#1]

Hi All,

  I have a script that runs several SQL queries in parallel to get around the character limit in the ODBC driver/SQL server since we frequently need to pull in data for WHERE clauses containing many thousands of strings, e.g "SELECT * FROM [Table] WHERE [id] IN ('id000000001','id000000002',...'id000010000')".  My method for doing this works fine, (iterate through a list of queries doing <<Run Background, inserting queryResult into a global list (::l_result_tables) in On Run Complete and updating global counter variables (::n_complete, ::n_error) to handle completion/error counts in both On Run Complete and On Error, then afterwards just awaiting (::n_complete+::n_error)==n_queries) but this generally runs faster and more smoothly if the Private flag is passed to <<Run Background.  After all queries have completed or failed, I concatenate/append ::l_result_tables[2::N] onto ::l_result_tables[1], then close tables 2::N.  Finally, I check to see if table 1 << Has Data View and if not, send it a New Data View message to display it for the user.

  All of that is to say, when I send the new data view message, clearly the "private" flag on the table is not reset, because the table does not show up in the table list on the main window.  Is there a way to reset or clear the private flag on the table, or do I have to generate the table as non-private during the <<Run Background call?  I've noticed that when closing the new data view, the "blank" space in the table list on the main window remains, which tells me that the table is still in memory.  Calling Close(dt_results, No Save) on the private table does seem to work, as does Close All(Data Tables), but if the end user just closes the window they wind up with a potentially huge memory leak (private table they don't know about with millions of rows).

[#2]

I've noticed this, too, only when <<Run Background is used with the Private keyword.  Same result when passing <<New Data Box<<Show Window( 1 ), instead of <<New Data View.  It also makes it so that you cannot manipulate the table through the menu, unless you save the table first.  For example, picking "Sort" from the table menu brings up the "Open Data File" window, since there is no active or "current" data table.  Has anyone found a solution?

[#3]

Actually, after my queries, the now visible data table does not show up in the data table list combo box at all.  The table is there in the Window List, but the box says "(no tables)."  Peculiar.

Current Data Table() gives an Empty() value, unless run inside a table script, which correctly yields Data Table( "Things and Whatnot").  However, even inside that table script, an attempt to reference Data Table( "Things and Whatnot") throws an error: "Cannot locate data table...."  It's interesting behavior, and I'd like to understand why it occurs under these specific circumstances.

[#4]

I'm glad that someone else has noticed this behavior, but obviously sad that there doesn't seem to be any explanation of the behavior forthcoming.  This causes an issue for me when a user runs one of my scripts multiple times in a row on single JMP instance.  The first time they run it, all is well, but the sneaky private tables have begun their mischief, because the next time they run the script, one of the first things it does is get the list of open tables (so they can use an open table to define what data they want to retrieve on this run).  That list is empty, but NTables() is non zero, so we wind up with an index out of bounds error.