One of the problems with a shared db model, where all developers work against the same database, is that everyone's changes are listed on the Commit List and any user can commit any other user's changes. It would be nice if an administrator setting could be set that would only allow users to commit their own changes There should be someway to prevent other users from committing your changes.

Most of our enterprise applications have mutiple instances of the same DB schema. We use the shared model and would like to update al instances once we commit changes on one of them. As a workaround we commit the changes and then hit revert changes on the instances we need to update

When using the 'Push to remote Git repository' feature in SC 4.1.8.41, add functional support for remote Git repositories that use SSH keys for authentication.

Create a way I can synchronize:

1. NON REPLICATED database X REPLICATED database
2. REPLICATED database X REPLICATED Database

Ability to syncronize tables/columns, views, sps, triggers, functions, indexes and constraints.
Avoid displaying individual constraints used for replication. E.g. Constraints that use range of IDs, Indexes of merging, etc.

== OR ==

Allow me to:

1. Filter Table COLUMNS by Name or part of it; E.g. 'rowguid', '% column name %'
2. Filter Constraint Name or part of it; E.g. 'repl_identity_%'
3. Filter Index by Name or part of it; E.g. 'MSmerge_%'

It would be mint* to be able to have SQL Server Maintenance jobs included in SQL Source Control. Could it be added as a new feature?

* (see kid from Super8 movie)

We occasionally restore a copy of production db over our development db. With SCC in place I imagine it will work like this:

1) Everyone commits dev changes that they care to keep

2) perform restore

3) One person relinks SSC in dedicated mode and uses "get latest" to pull down latest schema to the newly restored dev db.

4) everyone can resume working in shared model.

To cut out the relink in step 3, it would be nice to be able to use the "Get Latest" tab in shared model for occasions like this

We use the shared database development model and can have several projects going at once. Some developers may jump back and forth between projects. It would be nice to have the ability to setup a single database connection to multiple branches. Possibly using the SSMS registered server name instead of the physical server name.

When comitting:
Andy makes an edit and "Changed By" shows "Andy" (but does not yet commit).
James then makes an edit and "Changed By" is now "James", but does not mention "Andy"

It would be useful if it could show "Andy, James", to highlight a potential conflict.

When you get conflict when commiting changes it would be nice to be able to right click and open proc/table in new sql editor, do you change (merge) and continue.

We are a shop that have multiple systems for clients that we managed from within a single database, using a separate Schema for each system.

I would like to be able to link a TFS database to a filtered list of objects (preferably) an entire schema but I could see where others might like just a subset of other objects.

If this is currently possible please let me know but I do not see a way to accomplish this without having a separate database for each system per client.

We couple applications with schemas, not databases. It would be great to link source control to just one schema, rather than the entire database. This way, we can source the code for the application and the database in the same branch

Currently, when comparing an SSDT project using SQL Compare, it only loads the base project. If the project references another project as the same database (the standard workaround to the circular reference problem), the objects in the referenced project will not be compared. This can lead to changes being missed and deployments failing.

It would be nice if SQL Compare could follow the reference back and include the objects from the referenced database in the compare as well.

Similar to how fortress works with visual studio. All objects in the database would require an exclusive or shared lock to be worked. If an object is changed without a lock it becomes renegade for that user.

When developing in shared enviroment, I'd love a history tab that I can review all revisions with details, and not have to have a modal window separately. I believe this should be integrated into the main source control tab as change history log. This could help make others aware of changes made that could affect them, yet were already committed. Thanks!

I see the changes to be checked in , these may have been done by other developers. I want to compare the changes about to be checked in against the previous version to see what changed before I check in.

prevent timeout on commit changes tab for larger db in shared database model

Add an option in the SSC filter to ignore differences in filegroup location as there might be multiple instances of a controlled database that have different filegroup configurations

I don't see why is good this product if it's posible do commit to an object that is locked. If the object is locked this means that the user is editing it Then why allow to commit to this object