We realize that a lot of users work in a shared database model and hope to offer better support for this model in a future version.
We considered sharing the same set of "internal working files" across all the developers, but this can lead to a few problems because you could actually connect to the database from SSMS on another machine and then you might not have access to these "internal working files."
Another reason is SQL Source Control does not make any changes to the database. Therefore, there's no way for us to know if a different user has linked the database to source control or not.
There are probably some other issues that we'll hit when we start to work on supporting this better.
For now, linking the db is a one time thing, so I hope that is not too hard for each developer to do. If you have SSMS on a laptop and a desktop, you'll have to link each of these seperately because again, the "internal working files" are not shared.
On a shared db model, getting latest doesn't really make sense unless changes are made directly to the source control system or committed externally. In most of these cases, as the development continues, these will disappear from the different lists once everything is in synch. The issues are definitely caused by the "internal working files" being out of synch. The more often users visit the commit tab, the less likely this will happen. For now, I hope you can just ignore some of these descrepancies and just concentrate on committing the objects that you have made changes too.
I'm glad you found our recommendations post. I hope it helped.
Stephanie M. Herr
SQL Source Control - Project Manager