Working Bases in Wrong Folder

TheSQLGuru

Upgraded to v3, was told I could delete my v2 directory tree. Did so. v3 recreated and is using this path for working base:

...\AppData\Local\Red Gate\SQL Source Control 2\WorkingBases\ejfexi5u.g2a

csmith

Hi

Deleting the SQL Source Control v2 directory tree without first unlinking the database from SQL Source Control via the user interface would cause the behaviour you describe. Although, it is worth stating that SQL Source Control v3 will work fine with databases with a working base under the v2 folder.

However, if you'd prefer the working base to be under the "SQL Source Control 3" please unlink the database first, delete the unwanted working base folder and link the database again.

Best regards,
Chris

TheSQLGuru

csmith wrote:

Hi

Deleting the SQL Source Control v2 directory tree without first unlinking the database from SQL Source Control via the user interface would cause the behaviour you describe. Although, it is worth stating that SQL Source Control v3 will work fine with databases with a working base under the v2 folder.

However, if you'd prefer the working base to be under the "SQL Source Control 3" please unlink the database first, delete the unwanted working base folder and link the database again.

Best regards,
Chris

Correct me if I am wrong, but if I unlink the database I lose all historical information, rollbacks, etc, etc, right? This is a flaw in the system if so, and should not be required in any case. Your mandatory uninstall/reinstall to upgrade from V2 to V3 should cover this automatically.

csmith

If you unlink and relink the object history will not be lost. This is all stored in your version control repository.

By unlinking and relinking to the same repository location you are just making a new local working base for SQL Source Control to interact with.

Best regards,
Chris

TheSQLGuru

Thanks for the information.