Stored procedures/DB schema in source control

Do you guys keep track of stored procedures and database schema in your source control system of choice?

When you make a change (add a table, update an stored proc, how do you get the changes into source control?

We use SQL Server at work, and I've begun using darcs for versioning, but I'd be curious about general strategies as well as any handy tools.

*Edit:* Wow, thanks for all the great suggestions, guys! I wish I could select more than one "Accepted Answer"!

We keep stored procedures in source control.

Script everything (object creation, etc) and store those scripts in source control. How do the changes get there? It's part of the standard practice of how things are done. Need to add a table? Write a CREATE TABLE script. Update a sproc? Edit the stored procedure script.

I prefer one script per object.

create a "Database project" in Visual Studio to write and manage your sQL code and keep the project under version control together with the rest of your solution.

For procs, write the procs with script wrappers into plain files, and apply the changes from those files. If it applied correctly, then you can check in that file, and you'll be able to reproduce it from that file as well.

For schema changes, you may need to check in scripts to incrementally make the changes you've made. Write the script, apply it, and then check it in. You can build a process then, to automatically apply each schema script in series.

I think you should write a script which automatically sets up your database, including any stored procedures. This script should then be placed in source control.

We do keep stored procedures in source control. The way we (or at least I) do it is add a folder to my project, add a file for each SP and manually copy, paste the code into it. So when I change the SP, I manually need to change the file the source control.

I'd be interested to hear if people can do this automatically.

I highly recommend maintaining schema and stored procedures in source control.

Keeping stored procedures versioned allows them to be rolled back when determined to be problematic.

Schema is a less obvious answer depending on what you mean. It is very useful to maintain the SQL that defines your tables in source control, for duplicating environments (prod/dev/user etc.).

We have been using an alternative approach in my current project - we haven't got the db under source control but instead have been using a database diff tool to script out the changes when we get to each release.
It has been working very well so far.

We store everything related to an application in our SCM. The DB scripts are generally stored in their own project, but are treated just like any other code... design, implement, test, commit.