I have this huge legacy database that I'm trying to get under source control. I looked around here on stackoverflow and decided to use the Visual Studio 2008 database project, then committing stuff on svn. I successfully imported the schema into the project, but I can't find any way to use the user-friendly table designers with this kind of project. Whenever I open a table, it opens the DDL definition. I need the designers, otherwise I won't get buy-in from the team. Any suggestions/workarounds?
I'd use Microsoft® Visual Studio Team System 2008 Database Edition GDR. Which scripts every object in it's own file so makes it easy to track in version control.
For developers that don't want to use the tool let them develop in Management Studio and then use the Schema Compare tool in Database Edition to automatically extract out the changes from their development database into the project files when they are ready to check-in.
You may be able to write some (cunning) Visual Studio macros to do the Schema Compare automatically with the minimum of clicking for developers.
I found sql server management studio (express free or the full product) easier to use than visual studio database projects. The one good thing i liked about vs was that you could select multiple objects (e.g. all tables) in the server explorer and generate a single script for them. These are not easy to maintain but are good for a quick back up of all objects.
Management studio has the table and query designers and also allows execution plans and client statistic to be displayed so you can optimize queries/sps if required.
I have only used it with visual source safe for source control which works fine from Management Studio point of view, but vss is not great! (buggy, crashes, corrupts etc.)
Try opening the Server Explorer (View > Server Explorer). You may need to add a connection and then you can to the database tables, right click them and choose "Show table data".
0nce you're there you get the Query Designer toolbar and you're able to use the table designers.
Related
We are using SQL Server 2014 with Visual Studio 2015, we have a database project and a database.
Some programmers like to update procedures on visual studio and some others from management studio.
We have an issue, if you create the db project from database, all files created, for example stored procedures are generated with CREATE in tfs, same way the sp is saved on the database. When I do schema compare, all match. If someone use visual studio for altering one sp, he needs to change the file putting ALTER, this will allow developer to update the sp in the db from visual studio.
Now if I do schema compare again from db to tfs, I will have a new object to add in tfs because in the database is with CREATE and in tfs is with ALTER.
How can I solve this issue?
If someone use visual studio for altering one sp
This is the part that doesn't really fit with the "standard" SSDT workflow. SSDT generally assumes you are going to build a project (with or without TFS) and then update the whole database at once using "publish".
If you need to deploy single objects from Visual Studio, there are a couple of options such as "Quick Deploy" from https://agilesql.club/Projects/SSDT-Dev-Pack. This extension will let you deploy a single object (of some types) without changing the CREATE to an ALTER but bear in mind that using tools like this for routine deployment gives up many of the benefits (validation etc) of using SSDT in the first place.
"If someone use visual studio for altering one sp, he needs to change the file putting ALTER, this will allow developer to update the sp in the db from visual studio."
This is where you're going wrong. You mustn't change the files in the SSDT database project from CREATE to ALTER. If you want to alter an object in a connected manner (ie, on the database) you have a couple of options:
1) Open a query window (either in SSMS or from the Server Object Explorer) and execute an ALTER (note that this ALTER just gets executed and not saved in the project). You then run Schema Compare between the database and the project and apply changes to the project. Note that this isn't the supported/preferred workflow of SSDT. Instead it is designed to be used offline by changing the CREATE files, but this model won't work in SSMS.
2) You can consider ReadyRoll, which is developed at Redgate where I work. This is a database project in Visual Studio but it supports the connected workflow, which means that developers can make changes to a dev DB in either VS or SSMS and these changes can be imported back to the database project in a mouse click. This option has the advantage of being able to use the same development methodology in VS and SSMS alike.
Similar to this question, is there a way to visually display a database view in a database diagram?
Yes, though not using SSMS's Database Diagrams.
My solution for this is Microsoft BI's Data Source View (DSV). This requires that you have Microsoft's BIDS (Business Intelligence Development Studio), a component of SQL Server Standard (or higher) installed.
BIDS 2005 through 2016 should all work and provide the same basic functionality.
Alternatively, if you want access to a free version of the toolset, you can download and install SQL Server Express with Advanced Services ( basically SQL Express with Reporting Services added), though I have not worked with this version to verify.
With BIDS installed, launch it (or Visual Studio, if you have a more full version installed)
Go to File > New Project
In the New Project dialog, under Templates, expand Business Intelligence and choose a project. (I believe any BI project type will do. If you don't see any BI Projects, then you most likely do not have BIDS installed or at least installed with that version of Visual Studio).
Provide a location for this project to live on your machine.
Click OK to create the Visual Studio and BI Project.
In the Project Explorer pane, right-click the Data Sources folder and select New Data Source. Follow the Data Source "wizard" to create a connection to your desired data source. In the 2014 (and other?) version of BIDS, there is a question about the security credentials you'd like Analysis Services to use to connect to the data source. If you are just wanting to create a DSV for diagramming only, it doesn't matter what you select here.
Right-click the Data Source Views folder and choose New Data Source View. A Data Source View wizard launches.
Using the wizard, add the tables and views you would like to see in your data source view to the Included Objects pane using the left and right arrows.
Click Next to complete the table/view import and to give your DSV a name.
Click Finish to launch the import and see your initial diagram.
You now have a database diagram that includes both tables and views.
Here's a DSV of Microsoft's AdventureWorks2008 OLTP database. This image shows an example of what one can do with SQL views in DSVs. In it, I replaced the Employee table with the vEmployee View (gave it a friendly name of 'Employee') that exists in the database, and added logical primary key and foreign key relationships that mirror the PK/FKs of the underlying physical table.
Note that all changes made in a DSV are logical and therefore isolated to the DSV file itself and do not impact the database directly.
We originally dismissed using database projects in conjunction with TFS as our solution for our deployment and soucecontrol needs. However, in the interest of thoroughness, I'm exploring and prototyping it.
I've set up my database project (with add to source control checked). I've checked in the changes. Now, where do you develop from?
I've tried ...
connecting to the remote development server to make changes
syncing schema to (localdb)\Projects and making changes there
directly in the Source Control Explorer
With option 1 and 2 I don't see an automated way to add code to source control. Am I suppose to be working in the Source Control Explorer? (this seems a little silly)... Is there a way to commit the entire solution to source control? My apologies in advance, I'm a database developer and this concept of a "solution" is very foreign to me.
Also there were a lot of chatter about Visual Studios doing a lot of ugly things in the back ground that turned a lot of development shops off of database projects. Can someone share your experiences with me? Some of the pitfalls and gotchas.
And yes, we have looked at Redgate SourceControl (very nice tool).
Generally people do one of two things:
Develop in Visual Studio, via the Solution Explorer. Just open the project like you would any other project, add tables, indexes, etc. You even get the same GUI for editing DB objects as you get in SSMS. All changes will automatically be added to TFS Pending changes (just like any other code change), and can be checked in when you're ready.
Deploy the latest DB (using Publish in VS) to any SQL Server, make your changes in SSMS, then do a Schema Compare in Visual Studio to bring your changes back into your DB project so they can be checked into TFS.
I've been using DB projects for many years and I LOVE them! Every developer I've introduced them to, refuses to develop without them from that point on.
I'm going to explain you briefly how we use DB projects with TFS.
We basically have one DB already done and if we require any changes or new tables we create them or alter them directly in SQL Server (each developer has its own dev SQL Server).
Then in VS from the SQL Server Object Explorer we drag the tables we want into the DB project so when we check in the changes, every user in TFS would be able to get them and then publish that project that will generate and execute a script into the DB.
This is the way we use to develop when we need to add specific tables or records to the DB so we don't have to send emails with scripts or have them stored in an specific location (even with source control). This way we can get latest version of the project and publish it to ensure we have the latest DB version although it requires the user (who made the changes) to add them to the DB project.
Other way could be to do all the changes (and can be done without any problem) directly in the DB project and then publish it. That one would be a more right way to do it so you do all the changes directly in a source controlled project, but as you know, is always more comfortable to work directly through the SQLMS.
Hope this helps somehow.
We use the SSDT tools and have implemented the SQL Server Database Project Type to develop our databases:
http://www.techrepublic.com/blog/data-center/auto-deploy-and-version-your-sql-server-database-with-ssdt/
The definition of database objects and peripheral SQL Code (e.g. functions, sprocs, triggers etc) sit within the Visual Studio project and all changes are managed through VS. The interface is very similar to SSMS and, at this point doesn't cause any issues.
The benefits of this approach for us are as follows:
An existing SQL database can be imported into the SQL Server Project and managed through Visual Studio.
SQL object definitions & code can managed through the same version control system as the rest of the application code.
SQL Code can be checked for errors within Visual Studio in much the same way as you'd check your C# / VB for compilation / reference errors.
You can compare database schema's (within Visual Studio) between environments and easily identify key changes that you need to be aware of.
The SQL project can be compiled into a DACPAC file for automating deployment to different servers using a CI / Build Server (using the sqlpackage.exe utility without any custom scripts or code).
In essence developers can have a local version of the database to work on but would manage any changes through VS, then publish the changes to their local database. Once the changes are complete, the changes are committed to your version control system and then built centrally & automatically through a CI / Build server to ensure that all changes integrate and play nicely in much the same way that your other code is.
Hope that helps :)
I am needing to move all of my stored procedures into TFS 2012. I was wondering what the best/fastest way to accomplish this is. I am using SQL Server 2012.
Our suggestion would be to use the SQL Server Data Tools (SSDT) and create a database schema change management project in Visual Studio that you can then check-in to Team Foundation Server. It has quite a few benefits like being able to "compile" the schema and has tools that can be used in generating automatic change scripts for target servers (whether they are empty, test, or even production servers).
http://msdn.microsoft.com/en-us/data/tools.aspx
SSDT is definitely the way to go, It's a component of Visual Studio. There is an SSDT for database projects, and SSDT-BI for reports etc.
Create a database project in Visual Studio and add your database objects (stored procedures, views, functions, tables, schemas etc) into the project. It allows for all database objects to be stored in there (even database roles/users, certificates, keys etc).
Alternatively, you can use Visual Studio to import a database from a server. It will read your database and populate the project with all the objects from that database. It's very cool.
You can check in to TFS as you would with any other project which allows you to do versioning (with comments), attach that work to TFS tickets (if you manage your workload that way) and perform branching and merging and you can also compare different versions of the project or the project against already deployed versions.
Once you're happy with your database you can 'publish' your project up to a server of your choosing. This is a very useful method for creating code that can be deployed to multiple environments (i.e. different dev/test environments). You can also compare your project against a deployed version to see changes. For example, you could compare your project against a test environment to see what the differences are and generate a script to update the test environment to match source (or vice-versa).
SSDT is great for deployments because it calculates how to apply your database project (rather than just dropping the database and creating a new one). You can also use pre & post deployment scripts to work with data or add permissions onto your objects for example.
You can publish to a database/server, script or DACPAC (which is the format for copying your entire project/database schema and allows you to perform deployments/drift reports etc from outside of Visual Studio)
I need to create an entirely new Sql Server 2008 database and want to use a Database Project in Visual Studio 2010 (Ultimate). I've created the project and added a table under the dbo schema.
The table .sql is shown only as plain text, though with colors. It has no designer, no Add Column, and no autocomplete. Existing column's properties are grayed out.
Usually, I use DB Project for nothing more than storing .sql files for source control purposes, but I'm assuming it can help me with designing the DB. Currently, it offers no such help and I think it's because I'm doing something wrong. Perhaps I need to deploy the DB to server first, or something of the such. I've looked for a Getting Started guide, but all guides I found start from importing an existing database.
Please help my understand what a DB Project can do for me and how.
Thanks,
Asaf
The whole idea of the VSTS DB is to get you set on the right path, ie. store database object definitions as .sql files, not as some fancy diagram. Any modification you do to the objects you do it by modifying the SQL definition. This way you get to do any modification to the objects, as permitted by the DDL syntax, as opposed to whatever the visual-designer-du-jour thinks you can and can't do. Not to mention the plethora of SQL code generation bugs associated with all designers out there.
The closes to a visual view is the Schema View, which shows tables, columns, indexes etc in a tree view and you can see the properties from there.
By focusing the development process and the Visual Studio project on the .sql source files, teams can cooperate on the database design using tried and tested source control methods (check-out/check-in, lock file, conflict detection and merge integration, branching etc).
the deliverable of a VSTS DB project is a the .dbschema file, which can be deployed on any server via the vsdbcmd tool. This is an intelligent deployment that does a a schema synchronization (merge of new object, modifies existing ones) and can detect and prevent data loss during deployment. By contrast, the 'classical' way of doing it (from VS Server eExplorer, or from SSMS) the deliverable was the MDF file itself, the database. This poses huge problems at deployment. The deployment of v1 is really smooth (just copy the MDF, done), but as soon as you want to release v1.1 you're stuck: you have a new MDF, but the production is running on its own MDF and does not want to replace it with yours, since it means data loss. Now you turn around and wish you have some sort of database schema version deployment story, and this is what VSTS DB does for you from day 0.
You might be better off downloading the SQL Server Management Studio for SQL Server 2008 Express - http://www.microsoft.com/downloads/details.aspx?FamilyId=C243A5AE-4BD1-4E3D-94B8-5A0F62BF7796
Using this tool you can create your database using the visual tools provided by that software. You can run your .sql script to build up the database and then visually adjust columns settings, table relationships, etc.
Once you have your database designed open up Visual Studio and open a connection to this database using the Server Explorer.
Visual Studio is ok for simple tweaks and changes to an existing database structure but for anything serious like making the database from scratch I would recommend using the Management Studio. It's free and built for that exact purpose :)