This functionality has now been implemented and we have a new build which you can have if you wish. Please email support@sqldbcontrol.com to request a link for this new build.

Unfortunately it isn't currently possible to export all scripts in project in this way and I can't think of a workaround that would enable you to do this. This functionality shouldn't be too difficult to implement however so we'll try and fit it in.

Thanks Andrew, I've managed to duplicate this problem by chance and have as yet not identified the cause but will hopefully work towards finding a root cause.

KazMax:Hot damn. I rebooted the PC and it is now behaving itself. Stand the troops down.... Andrew Thanks for the update.

SQLDBControl 2.3, containing some new features and bug fixes, is now available for purchase and evaluation.  Version 2.2 can be downloaded for evaluation from www.sqldbcontrol.com/download.aspx. Version 2.3 requires .NET Framework 3.5 sp1, which enables us to offer full compatibility with SQL Server 2008. Feature ...

In the first instance we'll add the message to make it clear why tables cannot be rolled back.  We'll then try and work a way by which we can allow the user to override this default behaviour. Ideally it should overriding the default behaviour should be a little involved just to force users to make a conscious effort rather than accidentally ...

I've just tried this out now and I can only duplicate the behavior you describe with tables. Can you confirm whether this behavior is specific to just tables or are you also experiencing this on other object types? When we implemented support for tables we decided against allowing table changes being rolled back - primarily because a table ...

The attached file contains a script that creates a stored procedure called MoveDatabase, that will enable you to logically move a database and its objects to another server.  Create the stored procedure in the source control database. Naturally, the destination server needs to exist first so you'll need to add the server to the project if it ...

I can confirm that this is indeed the case. If you create a new project and import databases that already exist in another project all of the history is retained across different projects. I have however noticed that Labelling isn't maintained across projects. This is a slight oversight and can easily be remedied by modifying an existing stored ...

I'd have to confirm this but I'm pretty sure that if you create a new project and import the relevant servers/databases, as long as those databases are already part of another project on the same source control database, then their history is automatically imported too. I'll check this out later on and confirm whether this is the case or not.