Hi David.
On the offset, jisql is no longer a supported application. If you check the utils under jConnect 7, you would find the jisql app to be missing.
Anyway, on jisql 2.0.0523 I do not see this issue.
What version of jisql are you using? what version jConnect are you using? Both these version have a say in this.
Having said that, if I may theorize the scenario, the issue you are seeing *could be* due to the fact that when you have 'Automatically refetch results' turned on (this was the original default value - this has been changed in later versions e.g, 2.0.0523), the result set tab automatically regenerates the result set anytime after an INSERT, UPDATE, or DELETE statement is executed. When you are running a procedure like sp_who, which may have such a DML operation interfering with a SELECT in the procedure, this becomes evident. In older versions, you might even see some inappropriate error messages as well.
For example, if you execute a statement batch like
select * from T1;
(execute)
delete from T1;
(execte)
you will have the first result set updating to 0 rows
In some older versions, there was a bug which caused the following statements to return an error on the select result set
select * from T1;
(execute)
delete from T1; DROP TABLE T1;
(execte)
When you turned off 'Automatically refetch results', rightfully, you were not seeing 0-row result sets.
For the same reason, you do not see the behaviour you mentioned, when you execute a standalone SELECT statement.
Now coming to the second portion of your question...
When you change an option this way, you can save a.k.a lock the preferences by writing them to the username.prp file.
However, I don't think jisql is managing the locking of all the preference, and hence when you restart the app, you are back to the default value.
Can you check to see what version of jConnect/jisql you are using?