We have many DW databases, which popultae temporary tables (not #tables) on the fly, and regulary deletes them. We need an option to filter these specific objects out of the reposetory, as those objects has no value what so ever to the product.

It's possible to do it with SQL Compare, I hope you'll be implementing this soon, as right now we cannot really use the tool in an efficient maner.

@LukeW. - I just wanted to let you know that you should use SQL Compare to migrate your changes from Dev to Test/Prod. SQL Compare has filtering so that you can exclude objects and they won't be migrated to your target environment. These settings can be saved so it's only a one time setup. I hope this helps!

This would be a really compelling feature for my team- we're hoping to leverage SQL Source control to manage change to a battered legacy database where objects we want to ignore outnumber objects we care about 10 to 1. Not being able to exclude some objects makes it hard to see the forest for the trees, and seems like it will make migrating changes from test to production more confusing and risky.

Need an option not to include in source control certain DB objects. For example, I don't want to include tables, or user roles, or Service Broker.
For example I want to Source Control just Stored Procedures and UDFs, and if I create new table in linked DB, I don't want it to trigger the check-in event.

Would you be able to expand on this requirement. What are you hoping to exclude, and why?

I would like to see this via TFS as well.

I would like to see this via TFS as well.

Our application includes a SQL 2000 DB on SQL Server 2008. The DB has 23 table valued functions which keep recording changes, although the function's DDL has not changed. Does SQL Source Control regard the use of a table valued function as a source change?

Excluding REPLICATION objects, e.g., Stored Procedures sp_MS% is ESSENTIAL as in Production we replicate far more than in QA and Dev.

This would be useful. We utilize SQL notification queues, which create and re-create a number of non-persistent database objects associated with each queue that our web service uses. These don't need to be in source control. Also, when replication adds replication objects to our database, these are not items I would want in source control because they are not objects I would want to "get latest" from nor push to a test environment.

This would be a very useful feature rather than never ticking them when committing changes.

@David Atkinson: It would be important that such files will never reach the SVN repos at all, as they may be security related. In case of dependencies, it would perhaps be nicest to notify of these so they all dependent items can be ignored as well, or do so automatically (like all objects in a sub-schema other then dbo).

I also would find this very useful. In some of my development databases I am using cross-database views that are specific to that version of the database and that will always differ between the different versions of the database, same for the user objects between different test environments. Being able to exclude those objects would make everything much clearer when looking for changes not having been applied to one of the databases.

This is already suggested. Put your votes with this item. :)

http://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/458708-exclude-objects-from-versioning-svn-ignore-?ref=title

Also would be nice to exlcude objects by schema, and for team foundation server. We are currently experiencing performance problems with 'get latest' refreshing as we have hundereds of objects in a schema that is not ours and therefore dont wont to control through source control. This seems to have impact on our smaller schema which we have committed the objects for. It can take minutes to everytime you click on the get latest tab for the window to be refreshed. As a third party provider of software to an ERP system it is important that we can keep the ERP schema seperated and uncontrolled, whilst controlling our schema with the same database.

Is it important that they shouldn't be held in source control at all, or do you just want filter them out of the commit and get latest lists? If it's the former, it is important that they have no dependencies with any other objects, as the schema held under source control needs to represent a valid database.

Many of my databases include tables that are replicated from other databases. I would like to be able to exclude these from versioning since the table definitions 'belong' to the publishing database and not the subscribing database.

Duplicate Suggestion: Remove certain object types from source control
It would be nice to be able to disable certain object types from being added to source control via some kind of settings dialog. Specifically I'd like to not include user object types in source control and disable them from being shown in the change type window.

FYI - A few things you can do for now...
You can sort on the column headings in the Commit/Get Latest tabs. This will not filter the list, but will group objects by type or schema. You can use your mouse + ctrl or shift keys to highlight multiple objects in the Commit or Get List. Then click on the checkbox for one of the objects to select/unselect all the highlighted objects.

You can also right click on the stored procedures directory and click commit if you know you only want to commit changes to stored procedures. This will only select the stored procedures in the commit list and not select your other objects.

We would use this as well. The wildcards and both include/exclude would be useful.