I have a database I have inherited, and my best practice is to create the scripts to create the objects (tables, stored procedures and views) and then version control these.
It would like to have all the objects in this database scripted out, and put into source control; but on SQL Server 2005 (SQL Server Management Studio) it appears - at least to me - that the option to create one file per object that was available on Enterprise Manager has not made it through to SQL Server Management Studio.
Am I just not seeing the wood for the trees, or has the option that was there in Enterprise Manager not made it through ?
Does anyone have an effective way to create one script file, named as per the object ready for adding to source / version control ?
In SQL Server 2005 SP2, this is supported. If you select the option, it will give you files named after the objects, but also including the type of the object in the file name.
http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=124774
EDIT
Added link confirming that the change was in SP2.
Here is a link to a CodeProject vbscript that you can use to scripting all the objects of an SQL database on separate files. I have downloaded, modified slightly for my naming purpouses and it works great.
http://www.codeproject.com/KB/vbscript/0g_SqlExtract.aspx
Related
I have been working on a project which has a database project in it and I used to publish that database when ever I made some changes to the scripts. Now that I noticed that when I publish the database project it builds first and creates a dacpac file and then it publishes after I selects the target database. I am interested in knowing what role does that dacpac file plays in publishing the sql database.
Also I have found this thing when I was trying to read about pro's and con's about dacpac. Is it really works like that?
Link
The biggest problem with DACPACs has to do with the way a data-tier application is released to push version changes from the DAC into SQL Server. This is done by creating a new database with a temporary name, generating the new objects in the database, and then moving all the data from the existing database to the new one. After all the data has been transferred and the post-release scripts run, the existing database is dropped and the new database is given the correct name.
The dacpac file is the compiled build output of the database project. It's analogous to a .dll file built from a C# class library project. All of the information you defined in your database project about your database is stored in the dacpac file, along with information about the relationships between the objects.
When a dacpac file is published, the target database is compared to the dacpac and the tool will figure out what T-SQL to execute to make the target database match the dacpac's definition.
Regarding the article, note that the Data-Tier Application Framework that shipped with SQL Server 2008 R2 was largely rewritten/replaced for SQL Server 2012, so that article, while correct regarding that very old version of the Data-Tier Application Framework, is not correct regarding the tools available today.
The DACPAC file is a Zip file contains an XML representation of your database schema. It does not contain any table data (unless you provide pre-and-post deployment scripts). More information is available here: https://www.simple-talk.com/sql/database-delivery/microsoft-and-database-lifecycle-management-(dlm)-the-dacpac/
When a DACPAC is deployed, the receiving server compares the difference between the current schema and then updates your schema accordingly by generating a change script. However, be careful, as some changes can be very expensive (such as adding a new column in the middle of a table that already has millions of rows).
The article I linked to shows you how you can view the generated change script and see what happens. Repeated here is a snippet that does it:
"%ProgramFiles(x86)%\Microsoft SQL Server"\110\DAC\bin\sqlpackage.exe
/Action:Script
/SourceFile:MyPathAndFileToTheDacPac
/TargetConnectionString:"Server=MyTargetInstance;Database=MyTargetDatabase;Integrated Security=SSPI;"
/OutPutPath:"MyPathAndFile.sql"
Using DACPACs and Database Projects (in SSDT, but do not use SQL Server Management Studio) is the preferred way of pushing database changes now as it is less error-prone than manually redesigning tables using the table designer (which will drop-recreate-and-repopulate tables if you do things like add non-terminal columns to existing tables).
I'm not too familiar with it but played around with some database uploads myself. From what I gathered the dacpac has settings that can be used and uploaded. I found these instructions:
•To create a database project based on a dacpac, create a new SQL Server Database Project in Visual Studio. Then right-click on the project in Solution Explorer and choose "Import -> Data-tier Application (*.dacpac)" and select your dacpac. That will convert the contents of the dacpac into scripts in the project, and if you choose "Import database settings" the database options will be set based on the settings in the dacpac.
Dacpac is A data-tier application (DAC) is a logical database management entity that defines all of the SQL Server objects - like tables, views, and instance objects, including logins – associated with a user’s database. A DAC is a self-contained unit of SQL Server database deployment that enables data-tier developers and database administrators to package SQL Server objects into a portable artifact called a DAC package, also known as a DACPAC. from https://msdn.microsoft.com/en-us/library/ee210546.aspx
hope this helps...
What are advantages of using SQL Server Database Project in VS 2013?
Currently I dont use this on my project, I am generate script from SQL Server Management.
Should I move to Database Project? How complicated is?
There are many advantage of sql project.
1.Easily deployable in any conditions.
2.You can view history of db objects
3.You can maitain all db objects under on roof.
Effectively, a database project converts all of the objects in your database (table designs, stored procedures) into text files -- text files that can be searched, modified and stored in source control just like your code files. A database project also includes designers for working with these files. Visual Studio cross-references those files to give you a higher level of IntelliSense support for working with stored procedures than you'll ever get in SQL Server Management Studio.
You also get a staging database where you can make your changes before updating your production or development database and a schema comparison tool for determining, after the fact, what changes you've made. Effectively, you get an isolated database environment for trying out database changes.
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)
In MS SQL Server 2005, how can I create a script consisting off all the objects in the database (tables, stored procedures, views)? I want to use the script to create the database using SMO or to update its objects (alter, drop) if they already exist. I know about the scripting feature in SQL Server Management Studio, I am however not familiar with the configuration options.
If versioning your database schema is what you're getting to, try Wizardby. Although it does not directly support neither views nor sprocs, it supports running native SQL scripts as part of an upgrade/downgrade process.
I use Easy Sql Tools. The deploy version is free. You can generate scripts from schemas, data, indexes, almost everything.
http://www.easysqltools.com
There's a great tool SQL Compare that will actually compare two databases and create a change script for you. It's a great tool for staging purposes. There's also SQL Data Compare tool that will also compare lookup tables and act accordingly.
The downside is, they're not free. :(
How are the SQL objects managed with VSS?
Can I integrate SourceSafe / VSS with SQL Server 2005?
I want versioning in my SQL schemas.
Aside from VSS being a total train wreck, if you want to store your schema in source control, one possible approach is to store the object creation script for each database object as a separate file in source control. That way, you can update individual parts of the schema easily. So you have a script for each table, trigger, index, procedure etc. As part of your build process these can be pulled together into a single script for ease of application to the target database.
Utilize tools like SQL Compare from Red Gate which will allow you to create schema, object per file, and then maintain the state of the files with VSS. I am currently trying to push that in my organization.
We've just added Visual Source Safe support to SQL Source Control, providing source control integrated into SQL Server Management Studio. This is in early access at the moment so please sign up for the early access build and tell us what you think.
More detail is available here:
http://www.red-gate.com/MessageBoard/viewtopic.php?t=12265