lots of confusion for me while handling the VS Database Project. Okay, while trying to deploy the DB Project to a target database, the objects (SPs, Triggers) still refer to the previous database if included the reference of the same database in the objects. For example:
I have an SP which contains one of its table reference as DBName..TableName. After I deploy my project to a target database with a new name, the object still refers to the same DB which is DBName. Now to make my deployment work I change this hardcoded name to $(DBName) variable and this is passed along as the variable while deploying the Databases to the target DB. This gives an error while deployment. So can we deploy the database project containing cross references or references to the same DB to the new database target and get these names changed altogether.
Just try the "Publish..." Command from the Database Project Property Menu (right click on the project in solution explorer). Once the dialog is open you can set the values for your variables (e.g. [$(MyDatabase)]. If you choose the "Create publish script"-Option, a script will be generated containing SQLCMD-Variables which can be set to your target database.
Related
We have a database project that we publish to our local database. I have introduced a new database type and along with that a sproc that depends on it. Since the database project will not build unless the type exists, what would be the recommended course of action?
I want the database project's publish to create the type first, then build out the sproc. This will eventually make its way to Test, Stage, and Production servers, so it's important that it works locally first.
A buddy of mine found it -- I created the script as a regular script instead of finding the correct Visual Studio template "Add New Item > SQL Server > Programmability > User-defined Table Type", so the build action was "none" instead of "Build" as it needed to be.
I am trying to implement the CI/CD for ReadyRoll. For the release portion I am using an Azure SQL Server so I have specified the server name, db name and cred there. However, I am not sure what details do I give for the build component when creating the shadow db. I thought they were the same but then I get an error saying that its trying to create a db in my azure sql server and it fails because there's already a db with that name there. This led me to think I am supplying the wrong values but I am not sure what is that I am to supply.
ReadyRoll maintains two databases:
•Target database
This is the development database or sandbox that you use for
debugging and to edit schema objects (e.g. using SSMS). When you
deploy, ReadyRoll executes your migration scripts against this
database to upgrade it. You shouldn't drop the target database from
your SQL Server instance.
•Shadow database
This is an exact copy of your database schema created automatically
from your project scripts (001.sql, 002.sql, 003.sql, etc). It's
created every time you use the ReadyRoll DbSync tool to view pending
changes or import. The shadow database is used by the SQL Compare
engine (that powers ReadyRoll) as the base from which to generate a
new migration script. It is safe to drop the database at any time.
More information: Target and shadow databases
You can specify these arguments for shadow database: ShadowServer, ShadowUserName, ShadowPassword, ShadowDatabase. (You also can just specify target database)
More information: Shadow database
The sample for MSBuild Arguments of Visual Studio Build task:
/p:TargetServer=XXX.database.windows.net /p:TargetUsername=XXX /p:TargetPassword=XXX /p:ShadowServer=XXX /p:TargetDatabase=XXX /p:GenerateSqlPackage=True /p:SkipDriftAnalysis=True /p:ShadowUserName=XXX /p:ShadowPassword=XXX /p:DBDeployOnBuild=True
I have a data base that I've setup using composite SQL Data projects in SQL Server 2012. The main database has a reference to a library database and that reference is set to include in the same database. I can deploy it fine. However, when I try to do a compare, it ignores the library database. Is there some setting I need use to get it to compare to the full, composed database?
See:
http://blogs.msdn.com/b/ssdt/archive/2012/06/26/composite-projects-and-schema-compare.aspx
To deploy a composite project you must set the Include composite objects option on the project you're deploying from. ... This is available as an Advanced option in Publish and on the Debug properties tab, and as a general option in Schema Compare
I've created an SQL Server Database Project so that I can capture my database schema and add it to source control.
My problem is that the database contains Views which reference external databases. Given the business and project environment, this is an acceptable solution in the short tomedium term.
Sadly, this stops the database project from compiling, (since it don't contain the external database tables).
What are my options for getting around this error? I'm currently storing the schema in a single generated script, which is a pain to update.
Look at creating dacpac files out of the external databases and add them as database references. I did that by using the SQLPackage command line to generate the file, put the files in a "shared" folder (optional, but useful if this pattern persists with other projects), then add a database reference to the project. I recommend removing the variable for the DB name unless it can change in different environments. I blogged a bit about this here:
http://schottsql.blogspot.com/2012/10/ssdt-external-database-references.html
Now if it's a truly breaking change, I've done this through post-deploy scripts. Drop/recreate the view and reapply any permissions necessary. That's not ideal, but it can work.
In my database project, I have added a reference to a linked server. When I use this linked server in a view and try to build my database project, SSDT reports errors because it cannot understand references to any of the schemas referenced on the linked server:
[LinkedServer].[DB1].[dbo].[Table1]
The above would returns an error that SSDT cannot decipher the reference to [DB1].[dbo].[Table1]. I tried to add a reference to this database, but SSDT required either a .dacpac file (produced by another database project) or a system database on the same server as the database in my project.
How do I handle referencing an external database? There are use cases where a project needs to reference an remote database that is not an SSDT database project. In my case, I am accessing the database of another company and putting this database under version control as a SSDT project is out of the question.
Create a new SQL project for the remote database, place any objects in the project that you need to reference (doesn't have to be the whole database), and then add that project as a Database Reference to your project. You don't have to deploy the remote database, just have the definition of objects you use so they can be referenced.
The option we finally settled on was to use SSIS for importing of data. This way, transfer of remote data happened in an ETL layer. Our database did not reference any remote databases this way, which also can improve performance (eliminates transfers over the network, cross server joins etc).
I would recommend using SSIS or a similar method to ETL your data into local tables that your database project can reference (without needing an external project reference).