I'm working on a project which relies on the presence of a number of tables, views and stored procedures. Until now I have built these all in SQL Server Management Studio.
Now I would like to continue to work on them inside of Visual Studio. This will provide the benefit of version control (along with a number of other benefits hopefully).
I have added a new project to my solution and started working on one of the views. When I tried to build the solution it failed as the new project didn't have a server/database associated: Error 1 SQL03006: View: [dbo].[vw_Test2] has an unresolved reference to object [EV870_ACCT_MASTER].
I was able to overcome this by
-creating a dbschema dump using vsdbcmd.exe
-adding the dbschema dump as a reference to my database project
Is this the correct approach?
Now i can see the schema (tables, views, sprocs etc) in the Schema view (I had to enable display of "external elements") and the error message has gone away. Note: I had to reference like: [$(SQLDatabase)].[dbo].[EV870_ACCT_MASTER]
Now I want to know how I can work with these objects that i've scripted. I don't know how to use the new tables, views, sprocs etc (I want to use LINQ). Do i have to run the scripts first? How then if they are "CREATE OBJECT" scripts, will they run in future (presumably they'd fail as the object already exists in the database). Will my project/solution know which objects need updating and update them?
Ultimately want to take it a lot further- my aim is that the solution will be portable and a the server/database will be configurables. Then my tables, views and stored procedures will be created or amended if they don't exist or are out of date. Is this possible?
When I then start working with the views etc using LINQ I want those server/database references to remain dynamic?
I know there are quite a few questions in there but i'm hoping someone will be able to point me in the right direction- there doesn't seem to be much useful documentation online (or that i've stumbled across so far).
Thanks
Lee
Where I work (and the last place I worked) we distribute the sql scripts to create the database along with the app. In sql a version number is stored and when the app is run it checks to see if its version is newer than the number stored in the database. If so then it knows it may need to run some new sql scripts in case there were any schema changes. When this happens, we just run through all the scripts because they are written in a way that running them multiple times won't hurt anything... this way we don't have to worry about tracking which scripts are the new ones. Just check the version number and that's it.
As far as working with this stuff in Visual Studio instead of Management studio, I'm not sure why anyone would want to do that. Depending on what you use for source control you may be able to get hooks for Management Studio, but even if not that doesn't stop you from keeping your sql scripts in source control. And I wouldn't switch from working with my sql files in management studio to visual studio for the benefit of having built in source control any day.
Related
I have problem that is all my team members are altering the Sps and functions and
some conflicts occurred through the development
is there anyway or tool to store and get all version of them ?
the problem is before releasing the new version, i don't want a tool to compare difference between two databases like what Red gate SQL_Compare
thanks in advance
You may make use of the features in Visual Studio and TFS(or any other source control mechanisms). All that you need to do is to
Create a SQLServer DB Project in Visual studio and configure it to
your desired database.
Bind the project to a source control (TFS,
SVN etc.,)
Every time you have a change in DB, you can just compare the changes using .scmp file and click update.
You may refer this post for more information:
http://candordeveloper.com/2013/01/08/creating-a-sql-server-database-project-in-visual-studio-2012/
I am looking for information regarding Visual Studio 2013 and working with SQL Server projects using VS 2013. We are currently working on a project where were're using a database that already exists and is used by an ERP application. We're creating SQL Scripts that would alter and create fields on a table on the target database.
Now, we're not looking to "publish" those scripts, but create postdeploy scripts instead, which contains all the necessary SQL scripts in the order they need to be run. Everything is working fine. When we build the project, we get a fresh copy of the PostDeploy.sql script file that we run across a target database.
At the moment, the script looks at a table, if the column that needs to be added exists, it DROPS it and then recreates it. This is fine for the testing phase, but once we go live, there will be several stages of the databases that the code needs to be tested on. The column may already exist from before and in that case, we wouldn't want to DROP that column, instead, we want to do schema and data level compare and just get over the objects that are DIFFERENT, so that the column doesn't need to be dropped, instead just "updated". I hope I am not being vague when I ask this question.
I found this video: https://www.youtube.com/watch?v=AuVpmu9CKRY and I am not sure if that is what I need to do? I would love any suggestions from you guys..
Have a wonderful day!
Well, this isn't really the best use for SSDT/DB Projects. Ideally, you'd want to pull the schema into a project and tweak that project to look the way you want. Rename columns, change types, etc. Because it sounds like this is a 3rd party app, you'd want some environment that can serve as your baseline - when you run whatever upgrade script is sent by the vendor, it goes against that environment. You'd then want to pull the appropriate changes into your project.
Once you have a project that looks the way you want, you use the publish option against your target database. In your case, I'd likely recommend generating a script. If you're in the VS environment, you can take a look at both the script and a summary of what will be changed.
For data compares, I'd really consider something like Red Gate's SQL Data Compare (pro edition if you can). You can set up a data compare against your baseline and automate pushing the data changes. You can do that through post-deploy scripts, but you'll need to hand-code the data inserts, updates, and deletes yourself.
I've blogged about SSDT before and that may give you some ideas. Jamie Thomson has also written quite a bit about Database/SQL Projects and inspired quite a bit of what I've done.
http://schottsql.blogspot.com/2013/10/all-ssdt-articles.html
I need to include a Stored Procedure in Visual Studio 2013 which references another Database which is not part of the solution. I only refer to a very small portion of the external database which is itself big and complicated.
I know I need to add a reference to it so that I don't get warnings when referring to objects within the external database from within the Stored Procedure.
Adding that Database to a this or another Solution is not an option as its not part of our solution and importing that creates a whole variety of other issues.
I can see in older versions of Visual Studio that I need to create a schema file using VSDBCMD but this has been replaced by SQLPackage, but I can't see how to access that and whether it will need the external database anyway.
I've been going round in circles on this, so some pointers would be warmly welcomed.
I realize I am late to the party on this but perhaps it will still be useful to someone: You don't mention if this is a c# project or a database project.
I'll assume database as I not sure how you'd get errors otherwise on the internals of an SP.
The only way I know of to remove errors on cross-database references is to add the other database as a project in the database solution, add a database reference to the project with the sp, and then instead of using Database.schema.table syntax in the sp change it (in the database project) to [$(database)].schema.table
Alternately, a DACPAC can be created on the referenced database and used instead of referencing the database in an added project.
I'm new to this stuff myself, but I work with a lot of database cross-references in my sps so I am working through how to address this in database projects
I am adding continuous integration testing to an existing Visual Studio 2010 database project. Right now we have a build that deploys an 'empty' database [dbo].[MyDb] with just the reference data needed such as locales and countries. Right now this is performed using sql files containing insert statements that are run in the post deployment sql build task.
I now want to add another test deployment build that will deploy to another database on the same staging server as [dbo].[MyDb].[Test] with the same reference data but with generated test data that will have foreign keys to the reference data. Database integration tests are then run against that. Because the state needs to be restored for each test, this needs to be as fast as possible.
From what I've tried so far, to generate the test data using Visual Studio's data generation plan it seems I need to get the reference data to a form that can be read by the Databound generator so that it can generate the test data in a way that maintains referential integrity.
The possible options I can think of are:
Somehow get the data generation plan to read the reference sql files?
Change the reference sql files to csv files and change the original build to do bulk inserts
Combine the builds so that the MyDb database is always deployed first and set it as the sequential databound generator source for the test db.
Has anyone got a better approach or can point to a good guide?
I'm not an expert on build scripts so would like to take advantage of tools to do as much as possible. I want to keep things as a Visual Studio Database project but I also have a license for RedGate's SQL Tools if that would make the testing easier.
It appears that handling of reference data still isn't supported very well by database projects. This is confirmed by the comments on this post by Barclay Hill.
At the moment I've gone with the option of having a reference database and using that with a sequential databound generator. Since it doesn't change very often I just deploy it manually and have stopped short of having a whole separate project just for that as I've seen elsewhere.
Hopefully reference data handling will be added to SQL Server Data Tools at some point.
My Application Database Without Project and without Source safe, i planned to make my DB to be as project and add it to TFS, but I have no idea how to script the stored procedures, Triggers, Views, Functions, and what is the best practice to Make Update Script for All My stored procedures, Triggers, Views, and Functions to My customers DB.
The best procedure (IMHO) is to manually maintain a strict version of your schemas. Then when you need to make changes you write a delta script to move from one version to the next. I suggest you write the DDL scripts by hand -- you can make them concise and comment them.
You can use a tool like Visual Studio Team System for database architects, take a look at Running static code analysis on SQL Server database with Visual Studio Team System for database architects it will show you how to import the data, disregard the static code analysis that comes later it does not apply to your question
I've found a good way to get SQL scripts into SCM from an existing database is to use SMSS's "export all to script" option or whatever it's called, can't remember now.
Then every other change you add the change script into your SCM with a different version number in the file name.
Every release (or set cycle depending on your development/release methodology) you apply all change scripts, then re-script the entire database, tag it, and start again.
The best way to do it - save the database in TFS as set of database creation script, i.e. MyTable table should be added to TFS as MyTable.sql file (CREATE TABLE...) etc. We are using SQL Examiner to do this - see the following article: How to keep your database under version control
We are working with SVN and I never tested SQL Examiner with TFS, but I know that the tool supports TFS.