Turn on tracing
When a query fails and Access reports only „ODBC–connection to … failed“ or „ODBC–call failed“, the driver's tracing shows the actual reason: every request to the service, its response, and the message.
Solution overview
There are two kinds of tracing that complement each other:
| Tracing | Shows | Turn on |
|---|---|---|
| of the driver | what the driver makes of a statement: every request to the service, the response, messages, sign-in methods | TRACEFILE=<Datei> in the connection or the environment variable WKL_ODATA_ODBC_TRACE |
| of the Driver Manager (Windows) | every statement and every ODBC call of the application | ODBC Data Source Administrator, Tracing tab |
Implementation
- Set the environment variable for the user under whom the application runs, for example
WKL_ODATA_ODBC_TRACE=%TEMP%\wkl-odbc.txt, or addTRACEFILE=…to the connection string. - Restart the application; Access reads the environment and the connection at startup.
- Repeat the operation that fails, and open the file.
- Turn tracing off again afterward.
Result: For each operation, the file contains the connection setup, requests with address, HTTP status, and the service's messages.
Remarks
- Secrets: The connection string appears with
***instead of the values ofAPIKEY,PWD,TOTP, andSESSION. The driver doesn't write request headers. - Business data and personal data: The file contains, in plain text:
- the text of every statement of the application, including values that the application itself wrote into the text – if a password or a customer number is there, it's in the file too;
- the addresses of the requests with the values from conditions and the keys of changed records;
- when adding and changing records, the body of the request, that is, the fields of the record with their values;
the messages of the service and of the database, as well as signed-in names and Windows accounts.
The file doesn't contain the rows of the responses, the values of bound parameters of a passed-through statement, or the request headers. The replacement with
***covers only these four keywords of the connection string, not the rest of the text.
- Time: Tracing writes one line per
SQLFetchandSQLGetData, which noticeably slows down reading. Therefore, always measure times without it. - Hanging application: Every line is in the file immediately, even if the process hangs afterward. Driver Manager tracing, by contrast, buffers and is lost when the process is killed.
- Changed schema: The driver loads
$metadataonce per connection. If the service's schema changes, refresh the link in Access (External Data > Linked Table Manager).
Protect and share the file
Tracing is meant for troubleshooting, not as a permanent log of the data traffic. Treat the file like an extract of the business data:
| Question | Driver behavior | What you do |
|---|---|---|
| Who can read the file | The driver creates it without its own permissions; it inherits those of the folder | choose a folder that only the user can read, for example %TEMP%, not a shared drive |
| Several programs at once | Every process appends to the same file and lets others write too; the lines carry time and thread but no process ID | set a separate file name per program or attempt; otherwise the lines get mixed |
| How long it grows | The driver only appends; it never truncates, rotates, or deletes the file | turn it off after troubleshooting and delete it |
| Passing it to the support contact | – | review the file first, remove records unrelated to the error, hand it over through a channel approved for personal data, and delete it on both sides afterward |