Private Tables from SQL Query << Run Background, New Data View, table list not updating?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 <
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 <Data TableScriptingWindows
Re: Private Tables from SQL Query << Run Background, New Data View, table list not updating?I've noticed this, too, only when <
Re: Private Tables from SQL Query << Run Background, New Data View, table list not updating?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.
Re: Private Tables from SQL Query << Run Background, New Data View, table list not updating?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.
