Some of us might be still bound to VSDBCMD instead of using the new tools of SSDT like SQLPackage. As frustrating as it is, we need to also get around this and the limitations of the existing error Messages of VSDBCMD. The one you will encounter often is:
The database schema provider could not be determined from the supplied connection string. Check if the connection string is valid for the ADO.NET provider used for your database provider and that you have the privileges necessary to connect to the server.
So why can this happen ? The usual reasons are:
- The connection string is wrong (You won´t get a more specific error here, so check it character by character)
- You forgot to copy the Extensions folder over to your deployment machine.
- You forgot to copy the SQLTypes file.
...or the one you will probably encounter the more often in the future:
- VSDBCMD command does not support the version of the database you are currently connecting to.
Looking at DatabaseSchemaProviders.Extensions.xml file you will see the following Providers and the reason:
The versions of the Data Service Providers (DSP) translate to:
- Sql80 is SQL Server 2000
- Sql90 is SQL Server 2005
- Sql100 is SQL Server 2008
Your database isn´t within that range ? Well, then you are out of luck. There is no schema provider for you and therefore you are not able to use VSDBCMD for your development work. So if you cannot Change the Version of SQL Server, better get started with SQLPACKAGE and SSDT