This blog has relocated to https://blog.steveendow.com/. All future posts will be published there.
Let me share a common experience for Dynamics GP consultants and developers.
We frequently develop integrations, customizations, or software that interacts with SQL Server. It’s usually so dependable that we take it for granted.
Then, after months of flawless operation, you encounter this error at 1 a.m. on a Monday:
“A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)”
This is unusual because there have never been connectivity issues with the SQL Server previously.
When questioned, the IT manager reports no server problems and claims they would be aware of any issues.
The following Monday at 1 a.m., the same problem occurs for the second week in a row, affecting two separate integrations – one connecting to the live GP company and the other to the test GP company.
However, both integrations function properly when executed manually at 10 a.m., indicating that this is a persistent problem.
The IT manager reveals that the GP SQL Server is shut down every night between 10 p.m. and 5 a.m., which explains the situation.
While the cause was obvious in this case, it is frequently less so.
A malfunctioning switch or network card, custom code that locks or blocks SQL resources at specific times, or even a Veeam backup of a different VM affecting network connections are all possibilities.
I’ve witnessed custom SQL objects being deleted weekly due to a client’s security policy and antivirus software interfering with EXEs or DLLs.
Complex modern networks make identifying the root of intermittent problems challenging. People are hesitant to believe that anything other than your integration or software is to blame because hardware and software are typically dependable.
There appears to be a bias toward blaming your software, despite the fact that something else may be preventing it from connecting with the SQL Server.
I see this problem frequently, and when IT departments insist their systems are flawless, my options are limited beyond improving error handling and logging in my software.
While this may assist a dedicated technician in determining the cause, intermittent, non-critical errors are frequently ignored.
Do you have any strategies for persuading IT departments to investigate these issues rather than becoming defensive? I’d be interested in hearing any advice.
You can also find him on Twitter, YouTube, and Google+
http://www.precipioservices.com
