FWIW, the same is shown when using dbisqlc - although that one uses way less meta statements...

Say, for a "select @@version" run at '08:27:56' and fetched within a few seconds (surprisingly long, I guess because it was the only statement run so far), the idle count now tells about more than 3 minutes, and that fits nearly to the "LastReqTime" shown for the connection with sa_conn_info.

Should we conclude that the "Idle" property within an operations properties's "Statement timing" values is not related to the operation itself but to the connection as a whole?

I have written a simple Java application to test the profiler. The code is pretty simple:

public static void main(String[] args) throws SQLException, IOException {
    Connection con = DriverManager.getConnection("jdbc:sqlanywhere:UserID=DBA;Password=sql;");
    System.in.read();
    con.close();
}

It is interesting, but the profiler logged the "SET TEMPORARY OPTION ...." (many calls) as an idle connection. dbjdbc17.dll sets temporary options, and.... doesn't close them?! I do not know. You can write the Java application and profile it with the same settings what you used for dbisql.exe

Thanks

By default, a new connection will call the sp_login_environment procedure, and if the connection uses TDS (which jConnect does) that procedure will call sp_tsql_environment which does a whole sackload of SET TEMPORARY OPTION statements, which may be what the SQL Profiler is capturing.

For the full Penny Dreadful story see "Danger Will Robinson".

ALTER PROCEDURE "dbo"."sp_tsql_environment"()
begin
  if "db_property"('IQStore') = 'Off' then
    -- SQL Anywhere datastore
    set temporary option "close_on_endtrans" = 'OFF'
  end if;
  set temporary option "ansinull" = 'OFF';
  set temporary option "tsql_variables" = 'ON';
  set temporary option "ansi_blanks" = 'ON';
  set temporary option "chained" = 'OFF';
  set temporary option "quoted_identifier" = 'OFF';
  set temporary option "allow_nulls_by_default" = 'OFF';
  set temporary option "on_tsql_error" = 'CONTINUE';
  set temporary option "isolation_level" = '1';
  set temporary option "date_format" = 'YYYY-MM-DD';
  set temporary option "timestamp_format" = 'YYYY-MM-DD HH:NN:SS.SSS';
  set temporary option "time_format" = 'HH:NN:SS.SSS';
  set temporary option "date_order" = 'MDY';
  set temporary option "escape_character" = 'OFF'
end

Breck's test result does NOT show any change in SQL Anywhere behavior in this area :)

LastReqTime is the moment-in-time timestamp at which the last request for the specified connection started. It remains unchanged when no more requests have been started. That is expected behavior for idle connections. Foxhound uses LastReqTime and CURRENT TIMESTAMP to calculate and display the duration "Time Since Last Request" which is a more useful way to look at it; for example, if a connection displays "Idle" in the "Current Request Status" and the "Time Since Last Request" is 3h, that (probably) means this connection has been idle for three hours... of course, that request three hours ago might have run for a while, in which case the idle time is less than three hours.

Other than that, Time Since Last Request is not nearly as valuable as, for example, Transaction Time, or CPU %, or Waiting Time, or Busy/Wait/Idle %.

If SQL Profiler is showing that an idle connection is not idle, I would say that's a problem with the SQL Profiler. The SQL Anywhere server does not have any bugs in this area, as far as I know, nor does dbisql.exe.