Renamed Project Causes Local Files Corrupted Error
Akaoni
Posts: 3
We have just renamed an SQL Connect Project which works fine in Visual Studio.
When we go to link/relink the project in SQL Source Control (TFS) however, we get the following error message:
Clicking Yes causes the above error to appear infinitely, clicking No will prompt the following reportable error:
Looking in the above working base directory shows that the files there are outdated and don't match the renamed project files in TFS. If we manually get the latest version from TFS on that directory than the error stops occuring, but all our static data tables are unlinked.
How can we fix this so that SQL Source Control relinks to the renamed project correctly and keeps our static data?
When we go to link/relink the project in SQL Source Control (TFS) however, we get the following error message:
Local files corrupt
The local files relating to the database "<<database>>" have been corrupted. Do you want to re-link it to source control?
Yes No
Clicking Yes causes the above error to appear infinitely, clicking No will prompt the following reportable error:
Access to the path 'C:\Users\<<user>>\AppData\Local\Red Gate\SQL Source Control 3\WorkingBases\zimmxz2a.qz2\<<old project>>.rgproj' is denied.
Looking in the above working base directory shows that the files there are outdated and don't match the renamed project files in TFS. If we manually get the latest version from TFS on that directory than the error stops occuring, but all our static data tables are unlinked.
How can we fix this so that SQL Source Control relinks to the renamed project correctly and keeps our static data?
Comments
Off the top of my head I'd say TFS marked your .rgproj file read-only and all you need to do is un-tick the read-only box on the file properties.
And you may have got an older version of RedGateDatabaseInfo.xml from the repository. This file lists the tables whose data is under source control. I think the best thing to do would be to use SQL Source Control to source control the data again and then check in redgatedatabaseinfo.xml.
This was the issue.
If we link the database to source control and then uncheck read-only for both <<old project>>.rgproj and <<old project>>.rgproj.vspscc, it allows the working base to be updated properly.
Is this something you would be able to cater for in a future release of SQL Source Control (eg. When user clicks yes to "Do you want to re-link it to source control?", ensure read-only settings won't cause issues)?
Thanks for your help, Brian!!