I'm trying to automate my deployment and I've be trying to use the VSDBCMD command line tool to compare schemas of my development and staging databases. I can get it to work comparing everything but what I can't figure out is how to filter out the objects I want to be compared. At the moment it compares everything which means it wants to add or remove users, full text catalogs, file groups etc.
Basically I just want to compare tables, stored procedures, views, functions and a few other things. From within visual studio you can set what objects to compare but I can't see from the documentation how to do this using the command line tool.
anyone have any ideas?
Unfortunately you can't. The best explanation I have seen is here: http://social.msdn.microsoft.com/Forums/en-US/vstsdb/thread/75656877-95e1-4c13-8540-8a445f47ca57
I'm not at my workstation now, but I believe that it is possible to filter out user scripts by checking the "ignore permissions" option in the db settings file. You might try experimenting with the other ignore settings to see if you can get closer to your goal that way.
Related
I've just inherited a fairly large DB, and been just informed that the table structure does not match between Dev and Prod. This is causing us problems since the code developed for Dev ends up crashing in Prod which is causing some pretty catastrophic releases.
So, I'd like to find a way to compare the tables, keys, and indexes programatically. Adding a tool requires client approval which is quite the challenge. I can't just copy the data over because they have different data sets.
Does anyone have any scripts that could help me figure out which ones to update?
There are quite a few tools you could use. I prefer the Red Gate tool, however VS will work just as well.
Data is a non-sequitur, client approval is also a non-sequitur.
Simply script out the two tables, add them to your local client or a test server, use the tool to compare the two.
To expand on Tab Alleman's response it is typically SOP to roll Prod down to Dev. You can find tons of information on SDLC via bing / google.
A secondary option would be to rename the Dev version of the table, script out and "move" the table from Prod to Dev. Insert the data from the Dev version of the table back into the new table which will have the proper object name.
Perhaps simplest way without using any gimmicky third party tools is provided in the SQL Server Management studio it self.
Below are brief steps to give overall idea of actions involved:
STEP 1: Generate full database script for both the Dev and Prod databases using SQL Server Management Studio's inbuilt Generate a Script option.
STEP 2: Compare both the scripts using any basic text comparison utility (like Beyond compare, meld, WinMerge etc).
STEP 3: Note down differences and make plan to fix them.
and If you are still reading :)
More detailed explanation of generating database script:
In Object Explorer, expand Databases, right-click a database, point to Tasks, and then click Generate Scripts. Follow the steps in the wizard to script the database objects.
On the Choose Objects page, select Script entire database and all database objects.
On the Set Scripting Options page, select Save scripts to a specific location.
To specify advanced scripting options, select the Advanced button in the Save scripts to a specific location section.
Tricky step - In Advanced Scripting Options popup Select False for Include Descriptive Headers.
This will remove unwanted time stamps, which is a great help while comparing scripts.
On the Summary page, review your selections. Click Next to generate a script of the objects you selected.
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'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.
I have a 2 MS SQL 2005 databases,a TEST and DEV database. Now our developer added some extra columns,tables etc in the DEV database.This created differences in the TEST database.is there a script i can write tha can tell me what the changes where in the DEV database between certain dates...i found a couple of tools but they are quite basic and dont really generate change scripts etc. Also tried the change script function in management studio but it seems to be working when the change is first made and not later.
Appreciate your thoughts.
A.
redgate SQL Compare is a good tool to check for differences between databases and even sync them.
However, if you need to do this for free, try this: within in SQL Server Management Studio do the following:
1) script the entire schema of TEST to a file, look here if you don't know how
2) repeat step #1 but for the DEV database
3) diff the files using something like Beyond Compare, should have a 30 trial
I wrote dbscript, and one of its features is to compare two database schemas and create a migration script.
What you need is a way to manage changes to your database schema and then apply them in a controlled and consistent manner. Moreover, you need a single authoritative source for the database schema.
For all this, check out Wizardby:
(source: googlecode.com)
I was wondering if there is a way to automatically append to a script file all the changes I am making to my columns, tables, relationships etc...
The thing is I am doing a lot of different changes on a TEST db and the idea will be to apply this change script when I move the test db to production... hence keeping production data but applying all schema and object changes.
Is there an easy way to do this? Can it also migrate database diagram changes?
I have seen how you can create a change script each time I do a change but this means I have to copy and paste into a master file. Actually pretty easy!
I was just wondering if I was missing something?
Do not make changes to the test server using the UI. Write scripts and keep them under source control. You can test your scripts starting from backups of the live data and you can tune yoru scripts untill they achieve the desired result. Then you can check in the scripts for reference and later apply them on the live server. See this article Version Control and Your Database.
BTW, check out the SSMS toolpack, I think it may do what you want (I'm not sure). My advice stand none the less: version your schema, use explicitly created/saved scripts, use source control.
There's no way to directly generate a "delta" script in SSMS.
However, if every time you publish changes, you script out the entire database, including data, to SQL using the SQL Server Database Publishing Wizard you should be able to extract diffs between the versions and get your deltas that way.
If money is no object, you can purchase Visual Studio Team System Database Architect edition and use its fantastic database comparison tools to generate and version control exactly the diffs you want.
Try using TableDiff , that came with SQL Server 2005.
SQL Server 2005 TableDiff Utility
tablediff Utility
We have the process where when a developer gets done with a change, they then script it out and check it into Subversion. In Subversion we have a folder for Tables, Stored Procs, Data, etc. They script it out so it is repeatable (i.e. don’t insert the new data if it is already there.) This is important to do anyway so you keep the history of changes for a given object in the database.
In the past, we would just enter each of the files that we wanted scripted out into a text file (i.e. FileListV102.txt). When we were ready to make a release we would do “get latest” on all of the files (from VSS back then.) We then had a simple utility that would read the “file list” file and open each of those files in turn concatenating them into an output file. That is pretty easy to code.
We outgrew that and now we have a release management tools (which can be found here and will be on sale mid September), that takes all of the files and creates a big SQL script file out of it. It does it in the order that you would expect based on the folder names – so files found in the "Tables" folder are done before those in the "Data" folder, etc.
Either way, once you are done you have a big SQL script file that you can then apply to a fresh copy of production and that is what you test against.
I know I'm way late to the party, but I just wanted to add that there are tens of third party products out there. Some are very good, some are very cheap or free, and some are a mixture. I listed 22 here:
http://bertrandaaron.wordpress.com/2012/04/20/re-blog-the-cost-of-reinventing-the-wheel/
We have been using a relatively new software called Kal Admin.
It has Change Management feature and let distributing selected changes to other databases very easily. We used to do it by comparing two databases but it not satisfy our need for change tracking.
BTW Kal Admin has Metadata and data compare capabilities as well.