November 15, 2015 at 10:53 am
Hello All,
We're developing/deploying an MS Access 2013 FE with an SQL Server 2012 BE across a wide area network. Getting fairly frequent error #10054 - 'An existing connection was forcibly closed by the remote host.' Sometimes I can use Linked Table Manager in MS Access to refresh the table links but sometimes that doesn't work and I have to close the MS Access instance and reopen it in order to re-establish SQL Server table connections.
We've tried traces of course. Can see the #10054 error in the ODBC trace but we're hearing that there isn't any record of the issue in the SQL Server or OS logs.
Based on internet research, this error appears to be fairly common, but the potential solutions that I've seen so far are onesy-twosy, only applicable for limited environments. Can anyone provide or point to more information about possible causes/fixes for this error message?
Thank you.
November 15, 2015 at 7:43 pm
A clarification to my post:
The #10054 'forcibly closed' errors aren't sporadic events, as might occur with occasional WAN flakiness. The #10054 errors typically happen within 5 to 10 minutes of user sign on to the MS Access FE. The errors are very frequent, whether the end user is actively working or the FE is just sitting there. Of course, when the error occurs, the FE has to be bounced to regain connectivity, only to lose it again 5 to 10 minutes later.
Obviously we can't go to production like this, so any/all insights very much appreciated.
November 16, 2015 at 2:13 am
similar problem here....with a possible solution
http://www.sqlservercentral.com/Forums/Topic1704338-1550-1.aspx
________________________________________________________________
you can lead a user to data....but you cannot make them think
and remember....every day is a school day
November 16, 2015 at 12:11 pm
Is the MS Access front end an mdb file? If so have you ever tried using ADO? I know it is "old" and deprecated with newer versions of Access files but opening a connection and closing it as needed has advantages over ODBC and Linked Tables. I have found it to be much faster than ODBC and there is no need for a DSN nor a routine to auto-re-link using a DSN-less connection.
November 16, 2015 at 1:58 pm
Are you using one copy of the Access FE database? Since you're running across a WAN, you might try putting a copy of the FE on each local server that then connects to your back end. Probably too expensive a solution, but how about merge replication with a local SQL Server at each site?
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
November 17, 2015 at 4:57 pm
Hello All,
Thank you very much for the feedback and insights. We tried the SSCrazy solution and so far it seems to have worked. We're very optimistic. 🙂
Appreciatively,
SGR
December 26, 2016 at 5:37 pm
The SSCrazy solution? Do you mean the thread linked above, which in turn links to an article about a bug in Access 2010 with some suggested workarounds?
If so, the bug was never fixed, since it still occurs in Access 2016.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply