I have a .NET project. When I do a SQL Server Schema Compare between what is on a local SQL Server 2017 database to Visual Studio in the direction of Database --> Project, the compare lists all tables, views, procedures and functions that are in the database under "Add".
It is unable to see the database objects in the project, so it thinks it needs to add everything to the project. Nothing shows in the Target object definition panel for any of the listed objects
If I do go ahead with the update to add a table to the project, E.G. Exhibit table, then it appears as Exhibit_1.sql in the project alongside the existing Exhibit.sql.
However, some changes were made to procedures in the database that showed up under "Change" so I was able to update them as normal
If I reverse the direction of the compare to Project --> Database, it lists all of the objects under Delete
Local Database is SQL Server 2017 but was upgraded from 2008.
Compatibility level is set to 2017 in the database properties in SQL Server Management Studio
In Visual Studio I have set the Target Platform of the database to SQL Server 2017.
I have ticked "Validate casing on identifiers" and Database collation is SQL_Latin_General_CP1_CI_AS on both
Visual Studio is version v15.7.1 and .NET is 4.7.03056
Is there anything else I need to do for the SQL Server Schema Compare to show the correct comparison? Something in the comparison settings?
Related
I recently updated from Visual Studio 2017 Enterprise to 2019 Enterprise. In my solution, I have a database project where I develop my tables, SPs, etc. and use "Schema Compare" to update my database in SQL Server.
When I open schema compare, connect to the target database in SQL server, and hit "Compare," it seems not to recognize objects in the target database because it lists every object in my database project to "Add" them to the target database in SQL Server despite the fact they already exist.
I tried opening my database project in Visual Studio 2017 (where I originally developed the project) and schema compare worked as intended. The connection to the target database in SQL Server was the same.
I'm using
Microsoft SQL Server 2012 (SP1) - 11.0.3153.0 (X64) Express Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1) (Hypervisor)
and I need to copy the database architecture(Tables and their constraints) to a new database so I can extract the database diagram. The current database won't allow me to(extract a diagram), but any new database I create, will.
I tried creating one with the old ones mdf but it threw an error.
I tried to do an export, which copied all of the tables, but none of the constraints!!!
In SQL Server Management Studio, right click on your database, select Tasks, Generate Scripts. Select the options for generating tables, indexes and constraints. Use the generated script(s) to recreate a new database where you can create the diagrams.
Management studio->Right click on the database
Task->Generate script->Script entire database and all database objects
generate the script to a file/clipboard/new query window
Create new database schema from this script
If you have access to (friendly) developer they may have a copy of MS Visual Studio with SQL Server data tools installed; in it there is a handy feature called SQL Schema Compare that can copy whole or parts of schemas between databases.
I am trying to take a legacy database that is now on SQL Server 2008 R2 and create a database project within Visual Studio 2010 for it. There are several stored procedures that used some "on-the-fly" temp tables (the kind where you SELECT * INTO #NewTempTable) Obviously this causes some SQL04151 reference warnings in the database project.
Is there any way to fix or just maybe ignore these specific warnings? I know the immediate answer might be to actually declare the temp table within the procedure and define the columns, but at this point, that isn't an option.
This does not appear to be an issue with the latest database project type for VS 2010, installed as part of SQL Server Data Tools.
Try to install SQL Server Data Tools. After it's installed you'll be able to upgrade your database project to the new type by right-clicking it in Solution Explorer. (The new project type is backwards compatible with SQL 2008 and SQL 2005 and also comes with some significant improvements.)
FYI the new project type has a very generic name of "SQL Server Database Project" and you'll find it in the "SQL Server" template group as opposed to the "Database > SQL Server" group.
Turn SET FMTONLY OFF in your stored procedures.
From MSDN:
Returns only metadata to the client. Can be used to test the format of
the response without actually running the query.
Your issue is that by default Visual Studio has this setting turned on... which allows it to determine the format of the response without running the query, but this doesn't work if temp tables are used.
Here's a discussion of this issue on MS Connect: Improve FMTONLY Intelligence
Per Microsoft's response, this is fixed in 2012, but won't be addressed in earlier versions.
Lastly, here's a related discussion on the FMTONLY issue.
I just installed VS 2010 for the purposes of running someone else's DB project that was created using the 2010. In VS 2008 I was able to right click on a SQL file ans select "Run ON" to run the script on a given SQL Server. I don't see this option in 2010. Is it available and if so how do I get access to it?
The database project format that was included in VS 2005 and VS 2008 has been completely removed in 2010.
Rather than holding loose SQL files that could be run independently, it acts a bit more like a compiler. When the project is built, the SQL files are parsed and (for the most part) turned into an XML-description of the database schema.
If you're trying to create or update a database based on all of the scripts in the project, right click on the project name in Solution Explorer and select "Properties". Under the Deploy tab youchange "Deploy Action" to "Create a deployment script and deploy to the database". Specify the connection settings and database name.
When you select "Deploy" on the right-click context menu of the database project, Visual Studio will build the database deployment files and generate the database. It's generally intelligent enough to update existing databases as well, assuming the project was designed well.
If you're attempting a remote deployment to a production SQL Server, things get a bit trickier. There is no single set of SQL files you can run - part of the database schema is stored as XML.
Take a look at Link - it describes how to use the "vsdbcmd.exe" utility to deploy a database file.
If you just want to run a single SQL file or test part of one, open the file, right click, and select "Execute SQL"
DNRTv # 167 talks about VS 2010 Database Projects in detail.
As #ShadowChaser already mentioned, DB Project in VS 2008 simply had the scripts in it, and 2010 version is a lot more complex and has a lot more features.
I can't see to find a quick explanation of the differences so I can figure out which to use.
One is for a server one is for a Database? Im not sure what that means..
Basically we are doing a new web app and I want to see what these project types can offer me in terms of tracking the DB code/schema etc..
SQL Server 2008 Project: this is used to create a SQL-CLR module, e.g. create a stored proc, a function, an aggregate etc. in C# (or VB.NET), that will be run inside SQL Server.
When you create such a project, and you click "Add New Item" in Solution Explorer, you're given the choice of creating a stored procedure, a trigger, an aggregate, a user-defined function, a user-defined type or a helper class. These will all be compiled into a .NET assembly, which will be deployed to SQL Server and be executed inside SQL Server in the SQL-CLR runtime environment.
SQL Server Database Project: that's only a collection of SQL scripts to be run against a database, to create and manipulate database objects
In a SQL Server Database Project, you basically only get to add SQL scripts - .sql files. Nothing else, really. So it is indeed quite different from the SQL Server 2008 Project type!
The answer here doesn't seem to actually answer the posted question. "SQL Server 2008 Server Project" "SQL Server 2008 Database Project" are both things that exist in Visual Studio 2008 Database Edition, but sadly while there isn't one named "SQL Server 2008 Project" as the answer suggests, there is one "SQL Server Project" that matches the description. Moreover, there isn't a project type anymore called "SQL Server Database Project" (at least not in Visual Studio 2008 Team Suite), although the description given above seems to describe the much older database projects that were at one point available in VS.
After thinking about it further, I'm going to guess that marc_s doesn't have the Database Edition (otherwise known as Data Dude or DBPro) installed. Correct me if I'm wrong.
Sql Server 2008 Database Projects and Sql Server 2008 Server Projects seem to do basically the same thing. I would have hoped that the Server projects would be used for the installation and configuration, and change management of a Sql Server instance, while Database Projects would be used for individual databases inside them...but this doesn't seem to be the case. Has anyone actually been able to determine the differences between them?
After playing around for a bit, the only difference I've been able to find is that Sql Server 2008 Server Projects will always deploy to the master database on the server you deploy to, regardless of what kind of database you import (master or otherwise) when you create the project. So in that case, Database Projects are for your business databases while Server Projects are specifically for the master database on the server that houses your business databases.
Edit: After scouring the VS2008 documentation a little harder, I came across this specification:
"Deploying Server Projects
A database project can contain definitions for database objects, for server objects, or for both. In most environments, developers can change database objects, but only the database administrator can change server objects. You can enforce this restriction by putting server objects in a separate project (known as a server project). You can then restrict version control so that only your administrators can change the server project. In a staging or production environment, the server project and its objects will most often be deployed separately from the project that contains the database objects.
You deploy a server project by using the same procedures that you use to deploy a schema project."
http://msdn.microsoft.com/en-us/library/dd193413.aspx