The work around helped a lot. Teaches me to save off that XML file the next time I have to wipe my Windows installation.
But I think you are over thinking the answer a little bit. How about if at the Databases level, you had a link all with a browse to the root and then for each database it found, if there was a corresponding directory, just do the link? Then piecemeal in the missing ones.

I would like to add my vote to the request for this feature - ability to execute "SQL Source Control" commands from the command line for the automation purposes. We manage hundreds of databases and would like all of them to be source controlled. Manually linking, updating and committing would be very tedious. This process should be "automated".

@Nettec - you should be able to do this with SQL Compare's command line, sqlcompare.exe. You just pick the database as the source, and a scripts folder as the target. Then you use the svn command line to commit the changes. Please contact support@red-gate.com if you need more help. Command line switches for sqlcompare.exe: http://www.red-gate.com/supportcenter/Content/SQL_Compare/help/10.0/sc_cl_Switches_in_the_cl

I want the shared databases of our team in SVN. Right now I have to click through the UI each day or so. Please help me save time with the ability to automate.

Following changes made in SQL Source Control version 3.0.9.18, you can now pass around a config file to help get additional users linked to nemerous databases more quickly. This release is currently available via the Check For Updates option from the application's Help menu.

Disclaimer: This is clearly not a proper solution for this suggestion (we are planning to work on that in a future version of the product), but it might help you get other users set-up with fewer manual steps!

So, here it goes:

1. Setup SQL Source Control on one machine with all the linked databases that are required. Then copy the following file from that machine:
C:\Users\[username]\AppData\Local\Red Gate\SQL Source Control 3\LinkedDatabases.xml

2. This file should be placed into the same location (C:\Users\[username]\AppData\Local\Red Gate\SQL Source Control 3) on other machines where you would like these databases to be linked ([username] in this path should be the user who will be using the copied configuration on this machine).

3. So, when the new user connects with SSMS to the server where the linked databases reside, they should see green database nodes in the object explorer indicating databases linked to source control. However, when one of these nodes is selected, because SQL Source Control has not got a local working copy of the database schema, it will prompt the user with the following question and they should reply YES to this:
"There are no local files fore the database [database name]. Would you like to link it to source control?"

4. SQL Source Control will then create the local files it needs to work with the database and the user should be up & running.

It is worth noting that at the moment this does not work with Migration Folder locations (they cannot be copied in the above way).

Cheers,
Chris

If this would be implemented, it would be the final part to automating our nightly builds with database upgrade support. We can use the packager to generate the script but the update from SQL Source Control is a manual process. Please try to get this implemeted - it would be awesome!

+1 On this feature.

I currently work on a database-intensive software project. We currently work with 8+ developers on a single development environment, which contains 3 database instances containing 40+ databases in total. There is only one development environment and developers have no local workspace/database instance.

Manually relinking/updating each of these databases (for example linking to a newly created branch or when you want to bugfix in a previous release) would take too much time if this has to be done manually.

I know this is not the ideal development setup, but that is not the issue we wish to tackle first.

I like the appeal of SSMS source control integration and automatic change script generation that other tools lack, but the manual intervention required is just too big a problem to seriously think about SQL SC.

We would also like a way to automate the commands of SQL Source Control. Specifically, we have this situation.

1.) Each developer has their own instance of SQL Server with the same 8 databases.
2.) The developer can use SVN Switch to switch to the branch that they want to work on.
3.) The developer should be using the schema that goes with that particular branch.

As it is now, when we switch between branches, we have to go to each of our 8 DBs and do the following:

A.) Unlink it from where we were working
B.) Link it to the branch we are working in now
C.) Get Latest Updates to get things that don't exist but need to exist
D.) Undo changes to get rid of things that shouldn't exist.

It'd be great if we could automate A, B, C, and D for each of our 8 DBs. I'm looking into using AutoIT for this, but haven't started that process yet. I'd prefer something more "supported". We could possibly use SQL Compare for some of this, but the feature that we really want is the static data feature of SQL Source Control. That let's us version our lookup tables.

With the ability to automate this, we'd save a TON of time and prevent mistakes when switching between branches.

We have 19 databases, and dozens of developers. I would like to write a PowerShell script that sets these extended properties so developers can open up SSMS and start working.

Yeah... us too. Many databases. Need to get them all in there. Would like to add the whole server and have the hierarchy Server.Database all get added to TFS.

We hope to achieve this by storing a database-level extended property with the repository location. This means that linking a database won't require typing in the URL and folder details. I'm not sure this will make the next version, but hopefully not too much longer after.

We acknowledge that the one-off set-up is tedious when multiplied by the number of developers. In the next version we'll be starting to store metadata such as version and repository information in database level extended properties. This will allow us in future to auto-link databases once the extended property is detected. This won't make the very next release, but should follow shortly afterwards.

We also have a large number of databases. We also develop in a team environment with multiple database developers. The time it takes to set up source control on our two servers for one person is bad enough.

Since we can't simply export a "config" file of some sort to then send to the other database developers that means each of my team have to waste that same amount of time setting up their workstation. I can't afford that amount of down time.

Although I am really interested in this source control plug-in, I likely won't purchase until there is some way to automate the setup for subsequent developers.

@David That's it in one! Currently we have something home-grown which uses the existing API to create and sync a developer database, would be great if that could also link-to-source-control. On the API versus built-in debate: one could ask why the API exists at all in that case ;-)

@Kit - ideally we'd like to build any automation feature into the product rather than requiring you to automate yourself. Do you envisage that each developer has a way to browse a source control repository, select a version and build and link a database from that version in a single action?

Lookls like this request has been merged with a separate one I made for an API call to 'Link database to source control'. Note my request was specifically for an API call rather than a command line, though perhaps Red Gate would need to do one to achieve the other.

With this in place we could create a one-click developer setup, which creates a local database, synchs it with a specified version in source control, and links it to source control.

We've got HUNDREDS of databases. Dozens in active development.
Several obvious details are missing from the initial setup of a linked database. These are specific to VSS, but I'm sure apply to other SSC versions:
1) Remember the last used (VSS) Database path.
2) Remember the last Source Control Folder, BUT... SUGGEST the name of the new DB as the terminal project name.
3) Add a Check box to "Auto Commit" ALL objects.

The amount of retyping (or even copy/paste/edit) the same information over and over is quite annoying.

Command line access to SQL Source Control's actions is exactly what I need as well.

Command line access to SQL Source Control's actions is exactly what I need as well.