Just got the 2.2 version and found that the filters are database specific. Is there a way to set a "Default" filter that is used by all databases?

Also to my not on consistency. I was hoping to create a single default filter file and use it for both Source control and the SQL Compare GUI and SQL Command line. The GUI's are not compatible because of the parent nodes that define the server, instance, database name. Neither are comparable with SqlCompare's command line /ArgFile

@Chattabaugh - thanks for the request. We certainly hope that both tools can leverage the same information. If this doesn't work as expected by the time we get the early access builds out, do let us know!

It would be nice if this information was stored in an XML file that is consistent with the SQLCompare command line's /Argfile XML Schema. It would allow for consistent compare's during continuous integration.

The filter option would work for us providing there is a way to save the filter as a default. [for a linked database?] I would also like to see a way to propagate a "Standard" filter to all of our developer's systems. Either through copying a config file or stored with the RedGateDatabaseInfo.xml

I'd like to exclude permissioning changes from source control.

This is a must as we use your product and it wants to source control system replication procedures.

Yes!!!, a similar filter like sql compare would be great

Definitely workable. Excluding all SPs for replication and other-domain logins works fine in SQL Compare, so would be good in SSC, too.

If you introduce this ASAP and work on "other ideas" later, I'm fairly sure the community would be very appreciative...

I would like to see a situation where we only control what we put into control in the first place. Thus, we could add objects or remove them as we see fit no matter what type or name they may have.

That depends. What I am looking for is something along the lines of the following....
I have developers that create temporary procedures for a variety of reasons. Usually they will start with something like RAF_xxx RAF are my initials. I would like to ignore any procedures that begin with RAF_* so that we don't check-in procedures that really aren't ready for even a check in to source control.

Definitely, required for me. Especially those constraint auto generated names. I use TFS source control though.

Hi

I would really appreciate this feature for at least two reasons:

1) In some of our databases we have tables that are generated dynamically, so we don't want to keep a record of these tables.

2) In another database, we keep some temporary tables (not #tables, but permanent tables like "TRACE_TABLE_DELETE_ME" and "TEMP_DATA_TO_TEST_WITH".)

Thank you
Andrew

We have some DDL that creates schema objects dynamically; these particular objects, which fit a wildcard pattern, are essentially "non-static data" in and of themselves. Whatever I do at present, the database will show "changes pending" every time the normal use of this database updates these dynamic objects.

Ditto for actually considering a .gitignore file if the source control is done through a Git repo.

If this tool had a feature to only include some objects, but not all, we would be more likely to consider a purchase. We cannot utilize and all-or-nothing tool within SQL Server. It would be a lot easier to phase in source control with a feature like this.

Yes, we would also like to be able to exclude items using the source control product, without this we cannot really use this as a source control option. You can do this with tortoisesvn in regards to flat file source control.

I would like this as well to exluded the vendor's code. We use a naming convention for our custom objects so a simple filter with wildcard support would work fine.

We also have SQLQueryNotification queues and stored procedures that would be nice to automatically exclude.

We have dev databases on different domains linked to the same repository. The only difference is in some Windows accounts behind the logins and not being able to "ignore" this is a big pain.
Of course we could use SQL Compare to (frequently) synchronise almost everything to and from a single source controlled database but that would not really be the "Dedicated database development" that you recommend.

I would like to exclude certain database objects from the source control system.
In particular, assemblies & serice broker objects.

We have an application that dynamically creates service broker queues, services etc which generates clutter in the source control system.