Access Error (3155) ODBC: “Query timeout expired”.

It happened when trying to insert a new record into a linked table called “order”

I’m using ODBC driver 17 in this case and it happened twice. Not sure if the user tried to do it twice or if my code kept going and caused it a second time, but I suspect the user tried the same action twice.

I first suspected a slow or disconnected link to the database. This may be the case, although they have a fast network and a decent SQL server, however, other programs also use the SQL server. If this ends up being a problem with SQL Server availability, perhaps moving the SQL Server database to a new dedicated server might be a good answer if it’s possible.

I still need to track down the actual order the user was working on. I was able to test the general functionality in my development environment. The problem occurred when the user attempted to click on the Copy and Cancel button which makes an exact copy of the current order, cancels the current order, then switches to the new order.

Ugh. Sounds like I could have to play with settings on the ODBC timeouts, although the defaults have been pretty good up to this point and the problem does not seem to have repeated itself.

Probably some kind of temporary issue.

So at this point I am glad I have a log of all errors being saved to the database (although if the database can’t be connected to, i have no backup location to store the log to). It is interesting that the log was able to be written to, so it does not seem like a global SQL Server connection outage. There were no other entries in the log about it either.

In any case, the steps I plan on taking to work on this are:

1. Try the general functionality the user tried. If this works:
2. Try the specific functionality the user tried by recreating the scenario to the best of my ability. If this works:
3. Check the query that was being run. Look at the indexes on the tables. Could it have been a truly slow query that needs optimization?
4. Perhaps update the ODBC timeouts in the Access front end to give future queries more breathing room.
5. Maybe I can also check the SQL Server logs or the Windows Server logs on that server. Were there any server events happening at that time that were related?

From there, I’ll start working through my findings. This particular error does not seem to be a simple one, although if I can find a recreatable case, I’ll know a lot more…