nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Script executing differently on other computer?

Ressel

The following scenario: I have colleague overseas whom I wrote a script for. It is a script that loads data from a database, organizes the data in a table and puts a table script for control charting into the table. The table contains a few different products/processes and this one table script is targeted at only one of them (i.e., a tiny fraction of all rows). When I run the main and table scripts on my computer, they work beautifully. When my colleague oversea runs them (and I saw this on his screen during a telco), he gets the table from the database alright, and the table script executes but does fail wildly with regards to the row selection it is supposed to represent in the control chart. It is using hundreds, if not thousands of irrelevant rows from the or a wrong subset.

In the table script, I am not using "Names Default To Here (1);". My colleague has a different JMP version installed (17.0 vs. 17.2.) which I didn't expect should matter. As a first response, I sent a copy of my preferences exported using the Preferences Manager (with import/export), which did not aid resolution.

He then sent me a copy of his table and when I inspected the table script in it, I discovered a minor difference to what the table script looks like when I execute the script from the top on my computer:

On my computer:

On my colleagues computer:

However, when I ran the table script (i.e., the bottom version) in the copy of the table he had generated and sent to me via email on my computer, the table script executed just as intended. Alas, I am at a total loss of what is going on here.

What could be at the bottom of this, how can we fix this and avoid this issue in the future? Any best practices? Thank you!

Accepted answers

jthi

I would suggest adding Wait(0); instead of Wait() as Wait() will default to 3 seconds.

You could also change filtered rows to get rows where (might at least make debugging easier)

rows_of_interest = Data Table("table_1") << Get Rows Where(Contains(:Category_1, "some_category") & Contains(:Category_2, "some_other_category"));

Table_2 = Data Table("table_1") << Subset(
	Rows(rows_of_interest)
);

All comments

jthi

There can definitely be differences between JMP maintenance versions which could cause all sorts of differences/issues.

Does the script work correctly for your colleague if they separate the script from table script, add Names Default To Here(1) to start of the script and run it from separate script window?

Byron_JMP

-local data format differences can really mess up a query. (this might be determined by the operating system locally)

-version differences since about v14 rarely cause issues.

-If you have newer faster computer and database connection, and your college has a very slow computer and a bad network connection to the data base, that might be an issue. (might have to add some wait();, or dt<<runformulas();, or use begin/end updates to your code.

hogi

is caused by color unknown object messages:

in general the setting is very useful - if you accept that some "known" ones get colored as well.

The disadvantage of "unknown" messages: it's not possible to open the Scripting index via

Ressel

@jthi, the issue is just the same when I asked my overseas colleague to follow the diagnostic procedure you proposed.

@Byron_JMP, just as I see it during our video conferences, the initial script executes approximately as fast as in my location. I am also guessing that the laptops in our company are all of relatively similar specs. What is confusing is that when my colleague emails me the initial table he has obtained from the first or "main" script and I execute the table script in it, it does just what I'd expect it to do. So maybe line speed is not the issue

@hogi I do not have this setting activated, so in my case (and I have taken the screenshots on my computer from my JMP installation) it appears as if the scripting editor itself is only colour coding a message like a variable if there's a line break between "<<" and "message", while it executes just the same with and without line break between "<<" and "message" completely independent of the colour coding.

However, I think I may have narrowed the issue down a little. I have copied in below what I want the table script to do, what it looks like on my JMP installation and what it appears to be doing on colleagues machine.

// what i want the table script to do
Data Table( "table_1" ) << Clear Selection;
Data Table( "table_1" ) << Clear Column Selection;
Table_2 = Data Table( "table_1" ) << Subset(
	Filtered Rows(
		Contains( :Category_1, "some_category" ) & Contains( :Category_2, "some_other_category" )
	)
);
Table_3 = Table_2 << Split(
	Split By( :Col_1, :Col_2 ),
	Split( :Col_3 ),
	Group( :Col_4, :Category_1, :Category_2 ),
	Output Table( "table_3" ),
	Remaining Columns( Drop All ),
	Sort by Column Property
);

// what the table script looks like on my computer
// it does exactly the same as the above version, despite the line break before 'Subset'
Data Table( "table_1" ) << Clear Selection;
Data Table( "table_1" ) << Clear Column Selection;
Table_2 = Data Table( "table_1" ) << 
Subset(
	Filtered Rows(
		Contains( :Category_1, "some_category" ) & Contains( :Category_2, "some_other_category" )
	)
);
Table_3 = Table_2 << Split(
	Split By( :Col_1, :Col_2 ),
	Split( :Col_3 ),
	Group( :Col_4, :Category_1, :Category_2 ),
	Output Table( "table_3" ),
	Remaining Columns( Drop All ),
	Sort by Column Property
);

// what it appears to be doing on my colleagues computer
Data Table( "table_1" ) << Clear Selection;
Data Table( "table_1" ) << Clear Column Selection;
Data Table( "table_1" )  << Split(
	Split By( :Col_1, :Col_2 ),
	Split( :Col_3 ),
	Group( :Col_4, :Category_1, :Category_2 ),
	Output Table( "table_3" ),
	Remaining Columns( Drop All ),
	Sort by Column Property
);

Maybe the solution is to modify the table script like this?

// a solution to be tested?
Data Table( "table_1" ) << Clear Selection;
Data Table( "table_1" ) << Clear Column Selection;
Wait(); // this would be the new part per Byron's suggestion
Table_2 = Data Table( "table_1" ) << Subset(
	Filtered Rows(
		Contains( :Category_1, "some_category" ) & Contains( :Category_2, "some_other_category" )
	)
);
Table_3 = Table_2 << Split(
	Split By( :Col_1, :Col_2 ),
	Split( :Col_3 ),
	Group( :Col_4, :Category_1, :Category_2 ),
	Output Table( "table_3" ),
	Remaining Columns( Drop All ),
	Sort by Column Property
);

What do you think? Thank you very much for your help so far and also for any additional comments you may have. In case I figure out what the issue is, I'll definitely post it here.

jthi

I would suggest adding Wait(0); instead of Wait() as Wait() will default to 3 seconds.

You could also change filtered rows to get rows where (might at least make debugging easier)

rows_of_interest = Data Table("table_1") << Get Rows Where(Contains(:Category_1, "some_category") & Contains(:Category_2, "some_other_category"));

Table_2 = Data Table("table_1") << Subset(
	Rows(rows_of_interest)
);