This PR adds the possibility to account for the time the execution
spends within the driver. For that, it simply adds up the ticks
accounted between entering and exiting any ODBC API call.
With it, now one can estimate roughly how much time the driver code
runs, as well as how long the driver waits for the REST calls (previously
available).
This time accounting is done globally and possibly across multiple
threads. Its mostly useful with single-threaded use, though.
The PR also adds the possibility to use a much larger logging
"extended" buffer. This is useful in troubleshooting cases where larger
logging meesages are required (such as when an entire server REST reply
is JSON object is needed).
Both of these features are disabled by default (for all build types).
This PR adds the possibility to account for the time the execution spends within the driver. For that, it simply adds up the ticks accounted between entering and exiting any ODBC API call.
With it, now one can estimate roughly how much time the driver code runs, as well as how long the driver waits for the REST calls (previously available).
This time accounting is done globally and possibly across multiple threads. Its mostly useful with single-threaded use, though.
The PR also adds the possibility to use a much larger logging "extended" buffer. This is useful in troubleshooting cases where larger logging meesages are required (such as when an entire server REST reply is JSON object is needed).
Both of these features are disabled by default (for all build types).