cancel
Showing results for 
Search instead for 
Did you mean: 

What does RequestTiming Yes/No actually control?

Breck_Carter
Participant
2,266

According to the Help, the RequestTiming server option controls whether or not several properties are recorded or not, including (for example) the connection-level ReqCountActive property.

However, this appears to not be the case for ReqCountActive in 16.0.0.1512, plus others...

select property ( 'RequestTiming' ) AS a, 
       connection_property ( 'ReqCountActive' ) AS b, 
       connection_property ( 'ReqCountUnscheduled' ) AS c,
       connection_property ( 'ReqTimeActive' ) AS d, 
       connection_property ( 'ReqTimeUnscheduled' ) AS e;

Test 1 values are not NULL...
a,b,c,d,e
'No','543','542','950.78711352705','.156981241973538'

Test 2 values change...
a,b,c,d,e
'No','548','547','950.787889712401','.157067199690039'

Accepted Solutions (1)

Accepted Solutions (1)

This behaviour could be appearing because changes to the server option ‘RequestTiming’ are effective only for new connections (for the duration of that connection)

EDIT: Discovered here and now documented here

Breck_Carter
Participant
0 Kudos

I just noticed that the V16 Help actually says this "The change is only effective for new connections, and lasts for the duration each connection."

The behavior has actually changed between 12.0.1 and 16.0 which is leading to this vague statement in the Help for the next version of Foxhound...

  • Changing RequestTiming from No to Yes will not immediately affect existing connections.

  • Changing RequestTiming from Yes to No may or may not immediately affect existing connections, depending on the version of SQL Anywhere used for the target database.

...sometimes ya just gotta go with "vague" 🙂

Breck_Carter
Participant
0 Kudos

PS in V16 the following connection-level properties seem to be mostly unaffected by RequestTiming (they mostly always contain values)...

ReqCountBlockIO

ReqTimeBlockIO

Answers (0)