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.

Sometimes when I launch SSMS I see the "Source Control Credentials Required" dialog.

"""
Your source control system requires credentials.

Enter the user name and password for the repository:
"""

It's prompting me to update the expired credentials for one of my old development projects.

I don't want to update the credentials right now, but SQL Source Control is very persistent about it.

When I click Cancel, the dialog immediately reappears!

After clicking cancel about 10 times in a row, it finally stops asking.

Can you suppress the dialog on startup?

It would be better to ask only when it is really necessary, like when I want to sync the database with source control.

My SQL Source Control version is 3.5.4.332.

This was originally raised on the forum:
http://www.red-gate.com/MessageBoard/viewtopic.php?t=20226

Would it be possible to add under the Commit-comment field a dropdown or list which shows the data of a TFS-"Team Query"?
We have implemented a "CheckIn"-Query which shows the developer his open Tasks/Bugs/... so that he can just select out of this list while checking in the pending changes.
Entering the IDs manually is annoying and most of the developers don't do it because they have to go to the TFS first, catch the ID go back to SQL Server Management Studio and write the text.
In VisualStudio this works fine - the developers just change the tab and select the item(s) and commit the changes on the "pending changes" tab.

I think the most elegant solution would be if you present the possibility to decide if the checkin will be done on TFS directly
or only on the corresponding local TFS-files. If it happens only on the local files you could see them in Visual Studio and use the
functionality there - and more than that you could check in the SQL-Code together with the VisualStudio code at once.
But then you would have to make sure that you don't loose the change-history in order to be able to deploy the changes from Development to Acceptance and Production SQL-Servers.

It can and does happen.. you end up with objects that you know are in production but for whatever reason never got committed and put into a migration script. Or, you just aren't interested in ever putting a certain change live.. maybe they are dev only. Maybe they are irrelevant objects like users. Maybe a naughty dev put stuff live without going through the proper process.

In all the above cases I want to be able to remove the object from my "pending" list *without* reverting. I want to ignore them completely.

I am aware of the ability to filter but I find this cumbersome and unsuitable in the case where I know I will never be committing a change.

I'm hard pressed to think of any corporation that would take a migration script and run "as is". You will at the minimum have some standard code or comment block to put at the top and bottom of a script.

For example, in our particular place, we check the DB version before running a script (header), and stamp a version on success / error handle (footer).

We also have special statement which we need to put after each batch (where the migration currently places a "GO").

Needless to say, having to manually do this is time consuming. So my suggestion is the ability to customize what goes at the top, bottom and after each batch (GO) on the migration scripts. This would be a huge time saver.

If you are already allowing this, great (I am unable to join your beta as I'm in an agile dev team).

When using development tools to modify a schema, you can end up having applied a number of changes which cannot be applied without data loss using schema differencing and which need to be included in a migration script.

It would be helpful if there was some form of SQL trace which could monitor schema changes actually applied, and be used to generate a composite migration script.

If I use Enterprise manager, or Red Gate to refactor the schema, it is up to me to remember to save the generated SQL and any other SQL I might write along the way and compose a migration script.

I imagine this works well if you have very formal and proscriptive schema development procedures, but if you have a more exploratory style, you may find you have applied a set of changes that you no longer have the scripts for and can only do schema differencing to get from old to new.

If the DB statement execution was tracked, you could record all queries which had schema or data side effects and then have a simple of (complex) process to generate an amalgamated/derived script to do a proper migration of old to new.