Traditionally I have created simple databases using SQL Server Management Studio, then taken a backup and restored to an empty database online. That is the preferred way of my hosting server.
I recently started using Visual Studio 2013 database project options because I prefer that environment. I used this http://sanderstechnology.com/2013/schema-modelling-with-visual-studio-2013-preview/12336/#.VijncNKFO71 as my guide.
There are differences - I don't have the post deploy scripts option so I have created databases using PUBLISH which seems to be fine. There is one quirk which differs in all the examples I've looked at. When I publish, it creates the database with the name I chose and appends _PRIMARY. In the database properties it shows the database name but above that it shows FileGroup = Primary, so I'm assuming that is why? When I view the DB via VS2013 or SQL Server Management Studio, it just shows the DB name but if I want to attach the DB to a project I have to attach the _PRIMARY.mdf file.
In my ignorance I am assuming the _PRIMARY is a wrapper around the database? I am wondering why VS2013 does that and if deploying the way I do, as explained above, is this going to cause issues? Or am I simply doing everything wrong..
The database project automatically creates a filegroup named PRIMARY for the database. This becomes the default filegroup unless you change it (see project properties > Project Settings > Database Settings > Operational tab), but typically you don't need to.
The database project automatically uses the filegroup name in the primary data file's name, for example MyDatabase_PRIMARY.mdf. This is a good convention to follow in case you need to have multiple data files (ex: MyDatabase_SECONDARY.ndf, MyDatabase_FILEDATA.ndf, etc).
What VS is doing is perfectly fine. Data file names are arbitrary anyway. If you do need more control over how the data file is named then read How to name the filenames of a database and set its location in Visual Studio 2015 Database project?
I also suggest reading more about files and filegroups in Files and Filegroups Architecture.
Related
I work in a team of developers and we currently manage our SQL Server database schema (tables, stored procedures, user defined types, etc) through TFS and Visual Studio using a database project. We keep our local development copies of the database in sync using the Schema Compare tools in Visual Studio.
I'm currently setting up partitioning on a couple of huge tables of data which has resulted in 500+ FileGroups & Files based partly on what data we want to be on SSDs vs. spinning HDDs.
My question is, does anyone have a suggestion or experience on how to manage the database schema in TFS such that each developer doesn't have to setup the 500+ FileGroups/Files on each development machine?
The reason I want to avoid this is because
On our development machines we will only have a small amount of data
loaded based on disk space.
We plan to have a maintenance job on our production server to move data from SSD partitions to HDD partitions based on age. This means our production partitioning function won't match our development machines for very long anyway.
First, for your situation you can try to use server workspace. When you need to modify the files or projects, you just need to check out them.
When you use a server workspace, Visual Studio keeps only one copy of
each file. This can significantly reduce disk space usage and
improve performance when you have a lot of items. We recommend that
you use a server workspace if:
Your workspace contains more than 100,000 items.
You want to use Visual Studio 2010 or earlier versions to work with the workspace.
You need to use the Enable get latest on check-out option.
I'm not sure how did you handle the a database project. About how to put an existing database under source control, which consists of the following steps:
You create a database project.
You connect to an existing database.
You import the database schema from the existing database into the
database project.
You review the results that are shown in the database project.
You put the database project and its contents under version control.
You can also use a SSDT Database Project For Your Data Warehouse. Below is an example of how you could structure your database project (am only showing a few tables and views in the screen shots for brevity). You don't have to structure it this way, but in this project it's sorted first by schema, then by object type (table, view, etc), then by object (table name and its DDL, etc).
More detail info please refer this blog:Why You Should Use a SSDT Database Project For Your Data Warehouse
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 have a very simple database (just 3 tables and a dozen rows or so each) that is designed for use with an ASP.NET MVC 5 project. I am using Visual Studio 2013 Ultimate.
I want to be able to post my Visual Studio solution for others to download and learn from. These examples will often be Visual Studio ASP.NET MVC solutions that appear in my blog. I've successfully publish console-type applications but I've never published any applications that use a database.
In my current project, I'm using a connectionstring that begins with "Data Source=(localdb)\v11.0". What I don't understand is how to provide a copy of my existing database to my reader. Is it a physical file on disk? If so, where is it (it doesn't appear as a path in the ASP.NET/MVC-provided default connectionstring) and how can it be included in a downloadable Zip file for others to easily download and install? Does NuGet or GitHub somehow automate this process? For the records, I googled around and also didn't find any articles that discuss how to do this (admittedly, I used the search terms "share" and "database" and saw a lot of hits having to do with network sharing--not what I intended...).
Finally, if at all possible I want my users to be able to download the solution/project files and run the project successfully right away. I don't want them to have to go into web.config and edit connectionstring or other system/configuration/environment values.
There is no information on what type of database you are using ? i.e. (SQL SERVER / My SQL / Oracle)
Would share you on SQL Server and to share your Local Project with Database. There are two ways through which you can share Project (including database).
Share the BAK file with Project - Take Backup of your project and include the same in the Project ZIP file and upload. So if any user downloads it then it will restore the BAK file (Database file) and then can connect down project with database.
Share the Physical file (MDF and LDF) with Project -
(a). By default, MDF and LDF files are located in SQL Server >> MSSQL >> Data
(b). Concerned database MDF file should be taken and added in ZIP file (c). Person downloading will extract the file and Use SQL Management Studio >> Database >> "Restore Files and Filegroups" option (d). Restore the database and run the project
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 :)