I am having problems publishing a SSDT database project and registering it as a data tier application. Let me explain.
I have a database (A) which references two other databases (B & C) through linked servers. I have created projects based on B and C and snapshoted the projects to create dacpac's for databases B and C. I have created a database project for database A which has database references to B and C through dacpac's. I have set SQLCMD variables and modified the db project ddl scripts to use the SQLCMD variables in place of the un-resolved linked server names. The project builds!
I am trying to publish the project as a data tier application but keep receiving the following error "Databases registered as a DAC database must be hosted by an instance of SQL 2005 SP4, SQL 2008 SP2, SQL 2008 R2, SQL 2012 or SQL Azure". Incidentally I am running SQL server 2012.
I thought I would test whether I could register as a data tier application through SSMS. Within SSMS the option to "Register as data Tier Application" is grayed out. I therefore tried to "Export Data Tier Application" and received a number of error in reference to the linked server objects.
My question is; is it possible to deploy a SSDT database project and register it as a Data Tier Application where the project is using linked servers, or am I doing something wrong? If it is possible could some one provide some advice.
I have broken Google looking for the answer, so any help would be greatly appreciated...
I had this error recently so I'll add my solution for anyone else who comes across this, already added to the dba stack exchange
Turns out in my publish.xml I had RegisterDataTierApplication set to True. The first time I published the database it worked fine, but then I got the same error, as the database was already registered as a Data Tier application.
By setting to false (or unchecking the checkbox in the gui) it works fine.
Related
I have an SQL Server Project as a part of my solution in Visual Studio. It requires that I include some stored procedures that access a different database on the same server. This database is not under our control, nor is it accessible locally to the developers, or in our dev Server. And we cannot import that database because its a few TB in size. The functionality represented by this stored procedures does not need to be called in our dev environment, and only has testable data in the staging and production environments where the other database is accessible.
When we attempt to publish the project to our dev servers, or locally, the publish script generated by VS fails at run time because SQL Server can't generate a stored procedure if it can't resolve the references to the missing database.
I am looking for a way to setup the publishing so that it is selective based on the ##servername variable (ideally, but I am open to other realistic scenarios, such as a way to tell the SQL Server not to try to resolve those references)
Thanks
P.S. I hadnt thought of mentioning it until #larnu's comment, but an additional thorn here is that our dev environment is hosted as an Azure Web app and using an Azure SQL Database server. Even if I created a Mock database for the missing reference, Azure SQL will not allow my stored procedures to see them.
Related : Visual Studio 2013 (Professional Edition)
I am trying to create Data Migration Script to deploy the changes on Staging Server.
This works locally fine. But When I try to run the generated Script on Azure Database, I get TextPtr is not supported on Azure platform. I studied more about it & found that the newer editions of SQL Server (sply for Windows Azure (SQL 2014 may be)) has dropped some keywords/functionalities the list can be found here.
The Sql Database Project only provides the Schema Compare, but Data Compare is avilables in tools Section (where we can not set Target Project Type property).
I wonder how can I deploy/Migrate the changes made in one environment to another in such a Situation. Currently I had to overwrite the existing Database on Azure platform.
But this is not Identical also, for first time this could work but not for later, as there could be some changes made to the Staging or other environments.
I had a similar problem, when trying to migrate between a test and staging environment in Azure. As a quick fix, I got around the problem by just doing a "copy" of the dev database via the Azure dashboard.
I am working on creating a visual studio database solution so that i could deploy databases in a more managed manner. Following are the steps that i performed after adding some sample tables and SPs in the solution.
Deploy the database to my local machine (and a new database is created).
Add some mock data to the tables in SSMS.
Add couple of columns to one of the tables in the VS 2010 solution.
Build the solution and deploy the database again (this time it deploys only the changes made to the schema).
Verfiy that the existing data was intact and new columns have been added to the table schema.
Everything is working as expected till this point.
Now I delete the database manually which was created by the deployment.
Go to VS 2010 and deploy the solution (expecting that it should do a clean deployment of the database), however i get the following error :
------ Deploy started: Project: MyDatabase, Configuration: Debug Any CPU ------
Pre-Deploy: Starting script execution…
Pre-Deploy: Finished script execution.
MyDatabase.dacpac(0,0): Error :
-->Cannot upgrade the DAC for database MyDatabase, a database with that name does not exist. Specify a valid database name.
Is there any setting in my solution where i could specify that the deployment should do a clean install if the database does not exist?
Or
Do i need to write separate (database creation) scripts if the database does not exist?
I ran into this issue as well. I deleted the database and could not deploy again. Then I found this link. DAC application needs to be deleted in the SQL Server Management Studio.
http://msdn.microsoft.com/en-us/library/ee240822.aspx
To Delete a DAC application
In SQL Server Management Studio connect to the database
Expand the Management node.
Expand the Data-tier Applications node.
Right-click the DAC to be deleted, and then select Delete Data-tier Application…
Complete the wizard dialogs:
I deleted the application and was able to deploy again. I am still learning that DAC is application.
I am running SQL Server 2012 and VS 2010 with SSDT (SQL Server Data Tools) installed. My dev DB uses stored procs, functions, CLR objects, etc. It has a snapshot of prod data of about 500GB.
I created SQL Server Database Project and then imported the database. This created all tables, views, procs and functions files under schema names. Great stuff -- now I can do a version control just like in other VS projects, create deployments, etc. So far, so good.
But, I am confused as to what my development process should be for changing/adding procs/tables under SQL Server Database Project. It appears that any changes I make are applied to some LocalDb/Projects database and NOT to my dev database.
Am I suppose to author all my objects in that LocalDb, then Build and deploy to my dev database via Publish? I am worried about my existing tables in the dev DB since if the publish process drops and recreates tables, I will loose my prod data snapshot.
What is the right development process to follow in SQL Server Database Project?
Think of the source database (in your case, your database project) as being the "to be" state after deployment. When a deployment is initiated, the executable (SqlPackage.exe) compares the source with the target and generates a difference/delta script to make the target look like the source. This is why we no longer have to specify CREATE or ALTER; the tool figures it out. To answer your question about ongoing development, you can develop either way. You can develop in the project files and publish them to a common Dev database (say, if you're on a team), or you can develop in the database with tools like SQL Server Management Studio (SSMS) and synchronize with the project files with a schema compare (I use the latter technique because I like SSMS).
For deployment, you'll have to have SSDT installed on the machine from which you execute the deployment (SSDT ships with SQL Server 2012 and later; I don't know about SQL Server 2008). You can create scripts to simplify deployment. You'll essentially call SqlPackage.exe (it lives in x:\Program Files (x86)\Microsoft SQL Server\nnn\DAC\bin) with an action and a source. I use Publish Profiles as well to take care of most command properties. So an example deployment might look like this:
SqlPackage.exe /Action:Publish /SourceFile:MyDatabase.dacpac /Profile:MyProfile.publish.xml
For more information:
SQL Server Data Tools Documentation
http://msdn.microsoft.com/en-us/library/hh272686(v=vs.103).aspx
SqlPackage.exe Documentation
http://msdn.microsoft.com/en-us/library/hh550080(v=vs.103).aspx
Make changes inside the VS DB project.
Deploy changes to localDB to test
Publish the database to your production server. I prefer to use Schema Compare to do this manually, but you can also publish the project via the right click --> publish menu (which will also create a publishing profile), or using command line arguments. The publish process won't drop and create tables (unless you tell it to drop & recreate the entire db).
Alternatively, in the project settings you can change the connection string to point to your production server (as pointed out in the comment). However, I recommend against this, as it will then attempt to publish to the production server every time you run a local build (F5).
I am unable to use my database project after migrating from VS2010 to 2012.
All scripts for the database objects in the project are connected to the automatically-created localdb database. I am not interested in localdb since the database is large and I maintain it in a full-blown instance of SQL Server 2008 R2.
I tried all possible settings in Tools-Options-Database Tools-Data Connections-SQL Server Instance name to no avail. After re-loading the projects, it always restores the same connection to localdb.
My problem is that I need to refer from one database to another. I do it with synonyms:
CREATE SYNONYM [pcg].[practice] FOR [PcgDb].[Portal].[practice];
This script is automatically linked to localdb and the PcgDb on localdb has no tables. Hence I an getting an unresolved reference error 71501.
I tried also all combinations in Add Database Reference, even added my instance of SQL Server to the localdb linked servers, still the same error.
When you first create the SSDT project, the first step should be importing the target database; at that time you can specify you live instance of SQL Server. You shouldn't need to "get rid of" the local DB, it should just be ignored at that point. Perhaps this is happening since you migrated an existing 2010 project? In that case I would suggest you just create a new Project and do the import from the live server.