When you Deploy a BizTalk project, it has to update a BizTalk SQL database, which by default is called BizTalkMgmtDB.
Suppose you have been using BizTalk on the same server for days, weeks, or months, and you open someone else’s project, change the server name, and get the error below. That’s the specific case I’m covering here. At the bottom of the blog, I refer you to other possible solutions if you’ve never got it to work before.
error DEPLOY: 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: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) The network path was not found
Same Error in Screen shot of Visual Studio. Once in Error List and once in View Output.
Tricky Solution – Did you Save the Changes?
Ok, suppose you know the server is up, you just deployed another project, and all the settings are identical.
Here is a trap that I fell into more than once.
I opened a BizTalk solution from our source control. The prior developer had checked in the code with his machine name it. While I think that’s a bad practice, I have to continue and fix it.
So I changed from his server (machine) name, to (LOCAL), which means the server I’m running on right now.
Then I did a deploy and got the error. I did several times, and was getting very frustrated.
The settings you see on the screen are retrieved (and eventually saved) in the .btuser file.
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
Finally, when watching this file in NotePad++, I realized that changing the value on the screen does not save it in the file! You have to first either do a manual “save”. Not even backing out of the Deployment Properties seems to cause the save to happen. Thus, when I was compiling, I was using the old values on the disk, and not the values that looked plainly obvious on the screen.
If this is the first time you have deployed, the issue could be caused by other reasons.
Refer to this blog for general causes of not being to connect to a SQL server: Pinal Dave SQL Authority site – could not open a connection to SQL server
Hope this helps! Just be sure and click SAVE before you DEPLOY.