database-project

My team is working with a .NET 2008 DB Project in their solution so we have some way to persist the schema between machines and through development and keep things consistent. My preferred way of changing the database and keeping track of said schema is through the SQL Server Mangement Studio -- basically, I have a copy of the deployed DB project and make my schema changes to that so there isn't a chance of corrupting my personal development environment. However, when I'd like to move my changes to the codebase, I'm having to add the files manually which I feel might be unnecessarily time

When working with a Database Project in Visual Studio 2012, VS defaults to the "Design-View" pane when you add or edit a table. While you can work in split-screen mode, the T-SQL pane defaults to the bottom pane. As I prefer to work with T-SQL directly as opposed to the designer, I constantly am switching to make the T-SQL pane the top-most editor in order to work with the object. Unfortunately, VS does not remember this preference, so each and every time I work with a table I must change to make the T-SQL pane appear on top as opposed to beneath the designer pane. I've looked to see if there

I'm in the research phase trying to adopt 2012 Database Projects on an existing small project. I'm a C# developer, not a DBA, so I'm not particularly fluent with best practices. I've been searching google and stackoverflow for a few hours now but I still don't know how to handle some key deployment scenarios properly. 1) Over the course of several development cycles, how do I manage multiple versions of my database? If I have a client on v3 of my database and I want to upgrade them to v8, how do I manage this? We currently manage hand-crafted schema and data migration scripts for every version

Is there a way to reference another database from my database project without directly referencing it? For example, I want to be able to write something like this: CREATE VIEW View1 AS SELECT X FROM OtherDB.dbo.Table1 Your best bet is to add a database reference to your project. For VS2010 and lower DBProj files, you'll want to generate a dbschema file and add it as a database reference. For SSDT, you'll want to use a dacpac file. This works well for projects that are mostly static and you can even tailor them down to just include the objects that are relevant. VS2010, 2008 - http://msdn

What I would like to be able to do, is to be able to create a publising xml script in Visual Studio database project that defines a variable, that will be used to compose a script . My problem is that I get a Error: "SQL72008: Variable DeployType is not defined." if I don´t define the variable in the post deployment script like this ":setvar DeployType "varchar(100)" When I run the publish.xml the DeployType parameter is rightly set at the top of the generated script BUT that value get overridden with the ":setvar DeployType "varchar(100)". So to make this work I would need to manually remove

I'm running into a small but weird annoyance that seems to be happening to other people, too (for example, check out the revision history of SEDE ). I have a SQL Server 2008 database project in Visual Studio 2010 that works properly. When I go to commit/checkin to source control, I'm told that my DB project's .dbmdl file has changed , even when I've made no changes to the project! I'm not sure if the changes are triggered by building my solution (which also includes an ASP.NET MVC application and a unit test project) or by simply opening the DB project, but this is getting kind of annoying and

I've built a database in SQL Server 2008 R2 and am using Visual Studio 2010 Ultimate to create a database project for it. I've created both a SQL Server project and Database project to represent my environment based on this MSDN walkthrough . The schema comparisons for both projects work as expected and I'm able to replicate all changes server to project. However, it seems to have imported some environment specific configuration, such as logins, user/login mapping, local service accounts (e.g. NT SERVICE\MSSQL$SQLEXPRESS2008), etc. This seems not ideal because my impression was this database

I am developping an SQL Server Database Project in Visual Studio which is in fact a User Defined Function. In this project, I included Json.NET as a reference (using NuGet). I managed to publish (and make work) my assembly and the UDF to my SQL Server instance by first turning the database TRUSTWORTHY ON (since my project is UNSAFE) and then running this: CREATE ASSEMBLY [System.Runtime.Serialization] FROM 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Runtime.Serialization.dll' WITH PERMISSION_SET = UNSAFE; Which turns out to be an assembly Json.NET depends on (if I don't do it, I get

The problem I want to solve is to build different scripts depending on build configuration. Say we have two instances of SQL Server: Enterprise version with connected Linked servers LocalDb version for offline developing and unit tests Enterprise version has views for Linked servers when LocalDB substitues those views with local tables. Those Linked Server views and local tables have the same names and set of fields. So they are not included in build by default (Build Action = None). Instead they are included in build in BeforeBuild Target of the project file. <Target Name="BeforeBuild">