I'm trying to export my database to a .bacpac file. I get the following error:

(provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

The command I'm using is:

/opt/mssql/bin/sqlpackage /action:Export /SourceServerName:localhost /SourceDatabaseName:MyDB /targetfile:'/media/jake/1F171B4C75D06418/MyDB.bacpac'

The database I'm trying to back up is on a different ssd than my mssql installation. I don't know if that makes a difference.

I've been googling around for how to fix this and most people using windows had their similar problem solved by making sure that various windows services were running and starting them if they weren't. But I'm not sure how to check for the same thing in linux, but I think all the services I need are currently running because I can connect to the database via sqlcmd as well as through JetBrains' DataGrip application. So I know that a connection is possible. I just don't know why sqlpackage is having trouble connecting...

I've also tried variations of this command on the SourceServerName parameter:

/opt/mssql/bin/sqlpackage /action:Export /SourceServerName:tcp:localhost,1433 /SourceDatabaseName:MyDB /targetfile:'/media/jake/1F171B4C75D06418/MyDB.bacpac'

And the error is slightly different:

(provider: TCP Provider, error: 0 - No such host is known.)

According to the official documentation for SqlPackage on 2017 CTP 2.1, the command to export data and schema is as follows:

/opt/mssql/bin/sqlpackage /a:Export /ssn:tcp:<your_server> /sdn:<your_database> /su:<username> /sp:<password> /tf:</path/to/your/file.bacpac>

Looking at your command, it appears you're missing credentials, so I'd give this a try (I've shortened the other parameters as well, and removed the TCP port):

/opt/mssql/bin/sqlpackage /a:Export /ssn:tcp:localhost /sdn:MyDB /su:<user> /sp:<password> /tf:'/media/jake/1F171B4C75D06418/MyDB.bacpac'
  • Does the same error occur using SELECT statements inside SSMS, or sqlcmd? – Randolph West Jul 2 '17 at 19:14
  • sqlcmd yes, SSMS yes (through windows vm). I've since taken that other ssd and just installed windows on it and started this whole process over. If I use SSMS to restore the bak file, I don't have any corruption like I did on the linux side. – Jake Smith Jul 3 '17 at 19:21
  • Interesting. Do you have any thoughts as to what caused the corruption? – Randolph West Jul 3 '17 at 19:22
  • My only guess is that I was restoring something too old to be compatible with SQL server on Linux. No errors during restoration, but reads past a few thousand records would error out 😖 – Jake Smith Jul 3 '17 at 19:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.