My company does a lot of work with various Access databases using the .NET OleDbConnection object. We work with them on our local machines. On Friday, February 13th, 2017 things got a little strange. Everything ran fast except for the call to Close(). I spent the better part of the day on this, and for me the issue came down to an odd TCP Send embedded somewhere in the .NET framework.
Basically, I ran SysInternals Process Monitor, then ran a chunk of code that 1) opens the connection, 2) fills a DataTable, then 3) closes the connection. Process Monitor showed a 6-7 second delay between a TCP Send and Receive to one of 3 random IP addresses. Using a web search for IP Block and each address, they appear to all be owned by Microsoft and related to Windows Azure. The addresses were:
- 40.76.62.115
- 23.96.219.115
- 40.86.88.112
The IP address remained constant for the life of the application. If I closed and reopened the program, I'd sometimes get a different address, but the 6-7 second delay remained the same. And this ONLY happens when using ADO.NET and the ACE driver. Using classic ADO in C++ with the ACE driver didn't make the TCP Send, and the JET driver didn't do so in either ADO.NET or classic ADO.
So why is there even a TCP Send embedded in code that is local to my computer, and communicating with an Access database on the same computer?
Note that when I pulled the Ethernet cable and ran the code, it made several attempts at TCP Send, but it didn't wait around for the Receive. There appear to be several documented cases of this behavior but no actual answers:
- OledbConnection Close and/or Dispose are very slow, take 20s to execute
- OleDbConnection close method taking long execution time
- OleDbConnection Dispose very slow (2s)
Edit: I've submitted a bug report to Microsoft about this here.
