SQL Source Control and SQL Prompt may not know about an environment (i.e. a developer not having access to staging or production server) and there's not really a facility in either tool to store information about the version of any environment.

Thus, SQL Source Control has to ensure backward and forward compatibility when creating migration scripts - which then triggers Code Analysis Errors in SQL Prompt...! It is a mess to clean up, and frankly a waste of time.

I suggest a feature where I can define my environments in the Tab Coloring in SQL Prompt including a listing of what version things are and then have this information shared around.

Another possibility is some "future shared utility" where it has useful information that it passes to each tool.

I've been told this is by design: When upgrading SQL Source control from say v5 to v6 all of the source control linked db configs are left behind in the previous AppData folder (%localAppData%\Red Gate\ SQL Source Control 5\ in my example) not moved to the new upgrade version folder (%localAppData%\Red Gate\ SQL Source Control 6\)

This leaves a history of folders in every users profile, and for us 'from the beginning' users I've got v3-v6 folders that I shouldn't need.

I'm told this is for Network and rollback reasons.

I suggest a checkbox or some such thing during the upgrade process to allow for moving of the link files and other necessary items, into the correct folder. If SC needs it, move it. You could even warn me and say 'these files are 15GB in size and may take some time to move, continue or leave it?'

When we look on the Commit tab at all the changes which have been made to our test environment, it would be useful to be able to see if objects are still being worked on (and who by). Could we have a column next to "Last changed by" to indicate the user who has the object locked?

For example, if one of our developers is still working on a given stored procedure, they don't want me nagging them to check it in if it is a part of a larger piece of work, which will all be checked in together later in the week.

Equally, I don't want one of our other devs to commit this work to Source Control inadvertently (especially when it's been picked up as a possible dependency in someone else's work).

NB: We're using the Shared database model, if that wasn't clear from the above!

It is very hard to do manual database link to repository/SVN if dealing with large number of databases (200 plus within one team) across large number of source control group. Every team member has to spend time and carefully map repository folder.

One user perform manual link to repository and his/her/ setting validated by QA Team before distributing link config file (xml) to the user group.

The basic requirement is user should be connected with the DB server and pass the repository path and credential. you may design few screen to navigate and collect user input based on provider input config file that was generated by another user.

By automating the process of Link and Unlink across the user group to avoid issues/error, saving time, maintain consistency and improve processes etc.

Let me know if your team need any help for designing this process.

Thanks!
Perwez

We have found that Source Control object locking can cause severe lag and even instability in SSMS for distant servers. The additional lag affects the SSMS Object Explorer contextual dialogs (right-click). Often the dialog will timeout and fail to render or multiple tries. Although we are able to disable object locking via the RedGate_SQLSourceControl_Engine_EngineOptions.xml file it would be much nicer to have control from the GUI. This could be in the form of a global on/off switch, or could even add functionality to blacklist certain servers. Alternatively, you could build in some kind of functionality to detect servers with high-latency and automatically turn off object locking.

Presently a standalone migration script runs before the main block. This seems odd as the point is to migrate data and for that you need schema to be in place.

I would like to be able to add standalone migration scripts to the end of the main block.

We ship databases with some data populated. (This is not simple static data that can be managed using linked tables). We ship for example some out the box entities such as Roles, A base User, a base Organization etc. They have circular references so to insert we have to turn off table constraints, add the data and re-enable. It would be great if we could add the script to do this to the end of the migration block rather than to an object at check in.

I propose you type Migration scripts:

1 Schema Migration - you have this whereby it is tied to say a table update
2. Pre Action Migration - executes before any main part of the checkout
3. Post Action Migration - executes after the main checkout block

The inability to do this is causing quite a bit of cussing on Forums.

Regards

Phil

While comparing static data in SQL Compare, there might occur a "red herring" issue where SQL Source Control cannot see filtered table-data due to being read by a user unprivileged for Row-Level Security. Since SQL Source Control cannot see the table-data, it will then suggest to either

a) Fetch all table-data from the linked repository (causing all kinds of PK- and other constraint issues)
or
b) Commit the deletion of all table-data to the linked repository

We don't want to do either of these actions. Although bypassing Row-Level Security for an unprivileged user isn't possible, it is still possible for an unprivileged user to see the row-count and physical index-stats of a table both by querying system-tables and viewing the "Properties" page of a table. By doing this, it is technically possible for SQL Source Control to see if the rowcount of the table matches the rowcount found in the system-tables and, if they differ, provide a clear warning in the comparison window that this particular table is subject to Row-Level Security and that rows may be hidden to the user.