I'm creating SQL procedures in Entity Framework by using Sql methods in the migration. For example in an Up() I'm doing
Sql(#"SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE FUNCTION dbo.MyFunction
...
GO");
Now my problem is with the GOs: if I want to be able to script my migrations (for using on a live server) I need the GOs in the generated script, otherwise it doesn't work. However for running Update-Database without the -script option (for use while developing), it gets upset about the GOs.
I've found some partial answers:
How to add code to initialize sql database
The answer by Bart provides a method to call to divide the statement up into multiple Sql calls. The problem with this is that it affects the generated script when running with the -script option, so back to square 1.
How can I override SQL scripts generated by MigratorScriptingDecorator Also looks like it could be useful.
My question is therefore: is there either a way to know whether you're running the migration with the -script option, or a better way to script my SQL procedures in the migrations?
I have posted a similar question where someone actually gave me an awesome answer
here is the answer to it. I hope it helps.
basically you have to alter your configuration file of your migration configurator
Related
I have question about Entity Framework projects or ADO.NET.
How can other users use my project without import SQL database? Is there any method to automatically create database/tables?
Could you please give hints or reference article or something like that.
Thanks,
How can other users use my project without import SQL database?
If you have a project that is just starting a good choise is to use Code First. In this case every developer can use a local database.
Is there any method to automatically create database/tables?
Here comes the good part of Code first - the database will be generated for you. Another thing that helps a lot, in my opinion, is the seeding of test data - Use Code First Migrations to Seed the Database.
Further reading: Migrations
You can use enbedded dbs like derby,h2 etc.
Is there anything built into the Linq to SQL libraries that allow me to create an entire database from a collection of DDL files?
Lets say you have a collection of DDL files, one for each table in the database. Conceptually it would be pretty straight forward to call a create table function for each one and each one that succeeds (does not through SQL exception for example due to a relationship or foreign key error) pop the file name off the stack. For any that failed you could try to call the DDL again until it finally succeeded and all of your tables existed in the database ... however ... if there is something like this that already existed in say Linq to SQL or the Migrations project that would be great. Does anyone know if this exists already without having to combine all of the DDL's into a single script? Thanks in advance.
If you have Visual Studio 2008 or 2010 Professional or Above, it includes the new version of database projects. Which can handle that precisely for you (it will even validate the scripts before execution so you can see what errors exists).
I don't believe so. Linq-to-Sql is not really made for manipulating database schemas. You might have more luck with something like the Microsoft SMO libraries.
Use ADO.NET commands instead for that. That should be able to handle it, depending how complex each file is. As long as each file has on executable statement, ADO.NET commands may work fine for what you want to do.
My Application Database Without Project and without Source safe, i planned to make my DB to be as project and add it to TFS, but I have no idea how to script the stored procedures, Triggers, Views, Functions, and what is the best practice to Make Update Script for All My stored procedures, Triggers, Views, and Functions to My customers DB.
The best procedure (IMHO) is to manually maintain a strict version of your schemas. Then when you need to make changes you write a delta script to move from one version to the next. I suggest you write the DDL scripts by hand -- you can make them concise and comment them.
You can use a tool like Visual Studio Team System for database architects, take a look at Running static code analysis on SQL Server database with Visual Studio Team System for database architects it will show you how to import the data, disregard the static code analysis that comes later it does not apply to your question
I've found a good way to get SQL scripts into SCM from an existing database is to use SMSS's "export all to script" option or whatever it's called, can't remember now.
Then every other change you add the change script into your SCM with a different version number in the file name.
Every release (or set cycle depending on your development/release methodology) you apply all change scripts, then re-script the entire database, tag it, and start again.
The best way to do it - save the database in TFS as set of database creation script, i.e. MyTable table should be added to TFS as MyTable.sql file (CREATE TABLE...) etc. We are using SQL Examiner to do this - see the following article: How to keep your database under version control
We are working with SVN and I never tested SQL Examiner with TFS, but I know that the tool supports TFS.
When developing an application with lots of stored procedures, should you store them in some sort of source versioning system (such as source-safe, TFS, SVN)? If so, why? And is there a convenient front end way to do this with SQL Server Management Studio?
Yes. All code should be stored in source control.
Simply put, code is code and mistakes happen. It's nice to be able to go back and see what changed over time and be able to go back to those changes.
We have to add it manually to a source control system, but you can create addons for the Sql Server the Management System. I haven't ever created one to automatically add it to source control, but I suppose you could. Also, all the code is stored in sql tables, so you could in theory create a process or something to go through the table(s) and retrieve all the code and commit it automatically.
Update: I would always write extra code to check and see if the code exists and if it doesn't create a filler procedure and then the actual script do and alter procedure.
IF NOT EXISTS (SELECT * FROM dbo.sysobjects WHERE
id = OBJECT_ID(N'[dbo].[SomeStoredProcedure]') AND
OBJECTPROPERTY(id,N'IsProcedure') = 1)
EXEC sp_executesql N'CREATE PROCEDURE [dbo].[SomeStoredProcedure] AS
SELECT ''SPROC Template'''
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE SomeStoredProcedure
Doing a drop and recreate will remove all the user permissions you have setup for it.
ABSOLUTELY POSITIVELY WITHOUT QUESTION NO EXCEPTIONS IN ALL PERPETUITY THROUGHOUT THE UNIVERSE YES!
Get your database under version control. Check the series of posts by Scott Allen.
When it comes to version control, the database is often a second or even third-class citizen. From what I've seen, teams that would never think of writing code without version control in a million years-- and rightly so-- can somehow be completely oblivious to the need for version control around the critical databases their applications rely on. I don't know how you can call yourself a software engineer and maintain a straight face when your database isn't under exactly the same rigorous level of source control as the rest of your code. Don't let this happen to you. Get your database under version control.
I recommend that you do store them. You never know when you'll need to rollback, or dig into logic you may have removed..
Here's a good way to easily grab your Stored Procs into files that you can throw into whatever source control you desire..
Stored Procedures to .sql files
Storing stored procedures is a great idea. Its a pain though. Just how do you get all that stuff into subversion? You can manually do it, but then its tedious and you end up not doing it at all.
I use a tool from the subsonic project.
sonic.exe version /server servername /db databasename /out outputdirectory
This command saves everything to 2 text files. One contains database schema, stored procs, user accounts, constraints, and primary keys. The other one contains the data.
Now that you have these two files you can use subversion(cvs,source safe) to move it into source control.
More info for using The Command Line Tool (SubCommander)
Most definitely yes. Then the question becomes how you store them in source control. Do you drop and recreate the stored procedure or just alter, do you add permissions at the end of the script or in a separate script. There was a post on Coding Horror a while back about the topic that I found interesting. Is Your Database Under Version Control?
Sure you should.
In MS SQL 2008, you can do it right from Management Studio.
SQL is code. All code belongs under source code control.
That is all.
Absolutely.
Positively.
A set of SPs is an interface, that is likely to be modified more frequently than structural changes.
And because SPs contain business logic, changes should be stored in version control to track the modifications and adjustments to the logic.
Storing these in version control is a symptom of organizational maturity at a coding level, and is a best practice.
Most definitely.
You should.
To my knowledge, no such tool exists to automate this process. At least, five years ago, when I was considering building one, there didn't seem to be any competition.
We store our procs in Subversion, all your SQL Code including DDL should be in some kind of source control repository
SPs and table schemas for that matter are all assets that should be under version control. In a perfect world the DB would be built from scripts, including the test data, as part of your CI process. Even if that's not the case, having a DB/developer is a good model to follow. In that way new ideas can be tried out in a local sandbox without impacting everyone, once the change is tested it can be checked in.
Management Studio can be linked to source control, although I don't have experience of doing this. We've always tracked our SP/schema as files. Management studio can automatically generate change scripts, which are very useful, as table drop/recreate can be too heavy handed for any table that has data.
SQL procs also surely need the same security/benefits of version control as the rest of the code in the project.
As others have said, yes they should be.
I don't know of an easy way to do this with SQL Server Management Studio, but if you also use Visual Studio, database projects are a great way to manage this.
There are methods in SMO to generate scripts if you prefer to code your own scripting tool.
http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated
If you're not using asset management alongside source control, then I say throw everything in source control. Images, word documents, the whole shebang. Can't lose it, can always reverse any changes to it and if any machine goes down - nothing is lost.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Stored procedures/DB schema in source control
What's the best way to version control my tables, views, sprocs, etc? Preferably automated or at least semi-automated :)
Thanks
I asked this one yesterday and got some nice responses:
Stored procedures/DB schema in source control
The articles from K Scott Allen say it all:
http://odetocode.com/Blogs/scott/archive/2008/01/31/11710.aspx
Write migration scripts for all db changes and keep them in a repository. Enforce a policy of making all changes to the db only by running a script; that way there is a record of what has been done, and a way to revert it. Investigate whether there's a migrations framework available for your favorite language/db combination.
I use Visual Studio 2008 Pro create Database projects (Other project types -> Database). We already use SVN as a code repository, so a project with a bunch of .sql files representing your stored procedures is just another thing to put in the repository - you can see diffs/history etc. This works the same with VSS or any other repository you use.
The nice thing about Database projects is that your project will remember your connection string, and all you have to do is right click on a .sql file (or select all of them at once!) and select run to update it in the db. This makes it easy to update your .sql files from the repository and run them all to update all your stored procedures, verifying your database is updated in seconds.
You can also select create a LINQ project (Visual C# -> Database) and store all your LINQ code in your repository.
Hope that helps!
If you were super lazy you could use the SMO (SQL Server Management Objects) or if using SQL Server prior to 2005 the DMO (distributed managmeent objects) to script out all tables/views/stored procedures daily and then compare the script to the script in source control and if there are any changes check the new version in. You won't be able to necessarily have as pretty of a script as if you just created all db changes in scripts, but at least you can recreate all tables/stored procedures/views. For example, in my table creation scripts there are often comments.
Here is an article to get you started on scripting: http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated.
Again, this is mainly if you are too lazy to bother with version control and it won't help if you change something twice in one day. Also any data migration scripts still have to be saved and checked in because this won't pick up ad hoc SQL, only database objects.
I have written a DDL trigger which logs all the changes done to the definition of SQL objects (triggers, tables, SP, view etc). I could very well invoke extended SP from the trigger and store the details in another Database and use that as repository.
But if your team is really disciplined any source control should do the trick. The trigger is used as an audit mechanism and it's ideal for teams which are geographically scattered.
Try Randolph, One of the best SQL Version control tools I know.
I'm using Visual Studio Database edition which can export the schema from SQL Server in to a Visual Studio project. This is then stored in Source Control and can be deployed where ever needed. The VS Database project is just a bunch of scripts though and it's a clunky way of working.
A more robust method would be to use a database migration framework and if you're working with .Net check out this blog post for a good description http://flux88.com/NETDatabaseMigrationToolRoundup.aspx.
Update
As mentioned in the comments, this page is no more. So here is the last known snapshot from wayback machine http://web.archive.org/web/20080828232742/http://flux88.com/NETDatabaseMigrationToolRoundup.aspx