How to know if a table is a linked subset?

[#1]

Hello everybody,

I would like to determine (using JSL) if the current data table is linked to a main table or not.

I tried "<< Get Table Variable Names" but it didn't work.

Do you have any idea of how we can get this information?

Thanks in advance for your help!

[#2]

FWIW, assuming your code makes the tables, you can make linked or unlinked subsets as you require:

Names Default To Here( 1 );

dt = Open( "$SAMPLE_DATA/Big Class.jmp" );
// Unlinked subset
dt << selectRandomly(0.1);
dt2 = dt << Subset(LinkToOriginalDataTable( 0 ) );
dt2 << setName("Unlinked");
// Linked subset
dt << selectRandomly(0.1);
dt3 = dt << Subset(LinkToOriginalDataTable( 1 ) );
dt3 << setName("Linked");

[#3]

Thank you for your answer Ian.

However my objective is not to create a linked subset but to determine if an existing table is linked to another or not.
Sorry if I was not clear enough!

[#4]

No, I understood, but was implying that you could avoid the 'problem'. But if you want to tell retrospectively, you could do something like:

Names Default To Here( 1 );

dt = Open( "$SAMPLE_DATA/Big Class.jmp" );
// Unlinked subset
dt << selectRandomly(0.1);
dt2 = dt << Subset(LinkToOriginalDataTable( 0 ) );
dt2 << setName("Unlinked");
// Linked subset
dt << selectRandomly(0.1);
dt3 = dt << Subset(LinkToOriginalDataTable( 1 ) );
dt3 << setName("Linked");


// Function to determine if two tables are linked
rLinked = Function({dt1, dt2}, {Default Local},
	dt1 << selectAllRows;
	if(NRow(dt2 << getSelectedRows) > 0,
		linked = 1,
		linked = 0
		);
	dt1 << clearSelect;
	linked;
);

Print(rLinked(dt, dt2), rLinked(dt, dt3));

[#5]

Thanks Ian, that is indeed a quite convenient way to solve the problem!

I just need to go one step further. How can we do that if we do not know what is the potential main table (dt in your code)?

Do we have to test all opening tables or is there a faster solution?

[#6 · Accepted solution]

you might be able to use the table variable; it will need some testing because I'm not sure if it is always set (update: tried several ways to make a subset and it seems the table variable is always created): 

dt<<gettablevariable("Linked Subset")
"This subset is linked to Big Class"

// but not linked parent table:
Data Table( "Big Class" )
dt<<gettablevariable("Linked Subset")
""

This linked subset has a table variable

[#7]

Thanks for the suggestion Craige!

I tried "Get Table Variable Names" but not "Get Table Variable"!

I did some tests and it seems to work pretty well!

So far, there is just one particular case where it doesn't work. If I create a summary table linked to the original table, there is no table variable created.

Any idea for this last point?

[#8]

Yes, the 'summary table' scenario is the one I tried - Hence my replies above. But I'm still left musing over how your JMP session can get into a state where you don't know what's linked to what. But that's OK.

You could easily beuild a 'linking matrix' using 'NTable()' and what I've given above.

[#9]

I'm going with Ian's answer then.

Why do you need the linked table information? Maybe there is another approach. 

[#10]

Actually I am using a script which runs several analyses. In particular, it saves the residuals and other columns from the Fit Model platform, in the current data table. If this table is linked to another one, columns are saved in the original table and not in the current one and it makes fail my script.

So when a user launches the script, I would like to check first if the current table is not linked to another one. And since I am not aware of what the user did before, that is the reason why I am not able to know what could be linked to what.

Let me know if you need more explanations or if something is not clear!

Besides to answer Ian's last post, I see how we could build this linking matrix but if we have a summary table, I am not sure that the previous script will work. If I am not wrong when you select rows in the original table, nothing is selected in the summary table.

So unfortunately this case is still problematic.