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

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.

Problem:
Sysadmin role is required to see who changed a DB object. I am not permitted to have this role and I would imagine many devs are in the same boat. This means that when many objects have been checked-in by many users it is hard to pick out one’s own changes.
Solution:
Have an option when checking-in which adds a 1 line encrypted comment to the start or end of each object script. The comment would contain the username of the person making the check-in (and a control parameter like the time of check-in for instance)
This username can then be displayed in the ‘changed by’ field if the current user does not have the sysadmin role.

Problem:
Sysadmin role is required to see who changed a DB object. I am not permitted to have this role and I would imagine many devs are in the same boat. This means that when many objects have been checked-in by many users it is hard to pick out one’s own changes.
Solution:
Have an option when checking-in which adds a 1 line encrypted comment to the start or end of each object script. The comment would contain the username of the person making the check-in (and a control parameter like the time of check-in for instance)
This username can…

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.

We generally share one database, but occasionally our developers keep a local version. All of these point to source control, which we consider the 'official' version of the database. A developer could commit changes to source control from their dedicated database. They could even edit the code manually.

However, if we set up the shared database under the 'shared' model, we can't get latest from source control.

We currently work around it by setting every database as 'dedicated', even the shared database, but then we miss out on keeping track of which users made which modifications.

We generally share one database, but occasionally our developers keep a local version. All of these point to source control, which we consider the 'official' version of the database. A developer could commit changes to source control from their dedicated database. They could even edit the code manually.

However, if we set up the shared database under the 'shared' model, we can't get latest from source control.

We currently work around it by setting every database as 'dedicated', even the shared database, but then we miss out on keeping track of which users made which modifications.