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
Related
I'm trying to port my system to SQL Database (Azure instance) from SQL Server 2012.
I'm using Visual Studio 2013 and I have my .sqlproj with all the definition of my database inside.
Given that a number of SQL statements are not available in SQL Database (like "ON [PRIMARY]", filegroups, etc.), I should change a huge number of *.index.sql , *.pkey.sql, *.table.sql files.
Unfortunately I still need to cope with SQL Server 2012 installations (some customers are still on that infrastructure), so I would like to have instead a simple way to switch between the "SQLAzure" vs. "OLD-2012" syntax.
E.g. something like Compilation Symbols would be useful, or similar tricks.
Anyone has a brilliant idea on how to manage such an issue?
Thank you very much!
cghersi
You could use a migration tool like Sql Azure Migration Wizard (not an official tool, but really good) and then generate the *.sql scripts that are used on SQL Database (SQL Azure). Then you can create a new project that only has those files when you target SQL Database (SQL Azure).
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.
Hi after toying around with SQL Server 2005 Database projects, I have been pointed to the Visual Studio 2008 Database Edition GDR 2 extension (by our Microsoft rep), which allows for the creation of "SQL Server 2005 Server Project" projects.
As far as I understand it, this lets you create a project with all the shared objects (logins being the most useful to me) of the Dev instance. Then when you create a "SQL Server 2005 Database Project" you can reference the "SharedDev" project, and all the objects (logins etc) will be accessible from your Database Project (say MyNorthwind).
What I don't understand is, when I'm creating my "SQL Server 2005 Server Project" SharedDev project, should I create it from Master on my Dev instance, or from the Northwind Dev instance?
Has anyone got any experience of this? Searches at MSDN bring up really slim docs.
http://msdn.microsoft.com/en-us/library/dd193425.aspx
Maybe I'm over complicating things.
Thanks for anyone who can shine a bit of light on this.
You want to create your database from the "Northwind" db not from Master. This should result in your project containing scripts which will create the logins when you deploy.
Best resource for VSTSDB is here:
http://social.msdn.microsoft.com/Forums/en-US/vstsdb/threads
For what its worth: Logins are a bit tricky VSTSDB 2008. The tool really shines with the management of the objects.
So at work, my team is using a central SQL server 2005 database server for integration testing and I want to move to testing on my local database. The only problem is that the central database is in excess of 10 Gb.
I am interested in importing the data objects and a rows for each table to ensure I can be up and running. Can you guys advise me on how I can do this?
I have VS 2008 professional and SQL Server management studio express. Would I need VS 2008 database edition?
Thanks
-Venu
EDIT : I will try logging into the central database server and seeing if the host machine has better tools. Thanks kpollock, I didn't think of that.
Both 2005 and 2008 Express editions have 4 gb limitation.
Have you thought about making a db copy on central server and dealing with it (just restore it into new db with other name)?
See also BACKUP and RESTORE in SQL Server -- Full Backups
Looks like an SSIS job to me - which I think Express version of Management Studio doesn't have.
Or you could do it in C# calling Stored procs on the source database to extract the data if that's where your skills lie. (this is how I would do it as I think it's more widely comprehensible - but that's just my opinion).
If the database is live and new data comes in all the time perhaps you could set up the schema and reference data only then use replication to get the new data as it comes in (if you think that will get you a representative sample).
You will have to code up the sample extraction based upon an understanding of the schema - i.e. ensure you get a full set of linked records (e.g detail records for orders and all lookups e.g. customer, addresses, etc.).
I need to migrate Access databases to SQL Server 2005. Since this needs to be done from within a setup so that a customers' installation is transparently migrated to SQL Server 2005, I wonder if it is possible to automate the SSMA toolkit from Microsoft.
Actually SSMA had command-line interface (special console executable in the SSMA installation folder). It was available at some time but I'm not sure whether it made its way to last release. You should ping SSMA support about what versions had it and what examples of its usages are available. I hope this will help you.
To my own knowledge, such an automation is not available. But it is still possible for you to generate the SQL code that creates the database (the one that will begin with the "CREATE DATABASE" sentence) and launch it through your user interface on your SQL server.
To generate this code, you can
Create the access database with the Access toolkit
Generate the corresponing "CREATE DATABASE" SQL code with (for example) SQL Server Management Studio (right-click on database, choose "script database as CREATE". EMS SQL Studio offers a very nice alternative to SQL Server Management Studio
Save the code for further use
With EMS Studio, You can even decide if this code also updates the data. But I'd prefer to automate data transfer through code: you can for example browse the tables (in the right order, depending on relationships), open recordsets (one local, one SQL), and transfer data by browsing the fields (you do not even need to name them) with code like:
(localRecordset links to local table. can be DAO or ADODB; Adjust code accordingly)
(sqlRecordset links to the SQL server. can be DAO or ADODB; Adjust code accordingly)
localRecordset.moveFirst
Do while not localRecordset.EOF
sqlRecordset.addnew
For each field in localrecordset.fields
sqlRecordset.fields(field.name).value = field.value
Next field
sqlRecordset.update
localRecordset.moveNext
Loop