updating DB with change type Drop

Early Access Program for SQL Source Control

Moderators: Chris Auckland, David Atkinson, sherr

updating DB with change type Drop

Postby justin.collazo » Fri Feb 26, 2010 11:39 pm

I have 2 databases linked to one source control repository. I tried dropping a table in database 1 and committing the change.
I went to database 2, get latest tab. It's showing a drop needs to be done and the compare has a create table on one side and nothing on the other. I click get latest to update database 2 and it errors on "Scripting selected changes" Seems like the file is locked or read only. I looked at the \\AppData\\Local\\Red Gate\\ folder properties and the read only checkbox is "full". Guess that means some files/folders are read only, some aren't. If I clear the read only box then clicking "get latest" works as it should. I guess the question is, is windows locking the files or is SQL Source Control locking them as read only? I seem to remember doing this once before last week for another problem. How do I keep it from happening again?

16:23:15.808|Error |ng.ErrorReporterBase|7 |ProgressTask:Reporting error
RedGate.SQLCompare.Engine.SqlCompareException: Do not have permissions to modify the file C:\\Users\\justin.collazo\\AppData\\Local\\Red Gate\\SQL Source Control 0\\WorkingBases\\fc53bc1b-0e4b-4af9-9070-8aef7175a516\\Tables\\HumanResources.EmployeeDepartmentHistory.sql. Note that no files have been altered. ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 4274, offset:201 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 4277, offset:122 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 225, offset:37 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1718, offset:21 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 173, offset:53 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 156, offset:11 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 171, offset:109 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1666, offset:32 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1878, offset:23 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1083, offset:500
--- End of inner exception stack trace ---[/img]
justin.collazo
 
Posts: 2
Joined: Fri Feb 26, 2010 11:17 pm

SVN needs-lock settings

Postby sherr » Sun Feb 28, 2010 6:46 pm

SQL Source Control should NOT be locking your files. I think it might be a setting on your Subversion server. Do you have TortoiseSVN installed? If so:
1) Right click on C:\\Users\\justin.collazo\\AppData\\Local\\Red Gate\\SQL Source Control 0\\WorkingBases\\fc53bc1b-0e4b-4af9-9070-8aef7175a516\\Tables\\HumanResources.EmployeeDepartmentHistory.sql
and select Properties
2) Select the "Subversion" tab at the top
3) Click the "Properties..." button near the bottom
4) Is there a svn:needs-lock property? If so, remove it.
5) Click OK to close the SVN properties window
6) Click OK to close the file properties window
7) Right click again and commit the change to Subversion (this is just committing the change that a lock is not needed on that file)

Now, you should be able to commit the file from SQL Source Control with out getting this permission error. Please let us know if you still have any problems.

You'll want to talk to your SVN administrator about the settings on your SVN server and see if you can remove the svn:needs-lock on your area. This way, you won't have this permission problem happen again. You'll need to remove the needs-lock property from all your existing files.
sherr
 
Posts: 126
Joined: Thu Mar 19, 2009 12:45 pm
Location: Cambridge

Postby justin.collazo » Mon Mar 01, 2010 11:31 pm

I checked for svn:needs-lock as you suggested, but it wasn't there.

I tried linking a new database to reproduce to problem since I had worked around it on the other database by clearing the read only property in windows explorer.

I'm having the same problem with the new DB. I have the proper security rights in windows and SVN. The server settings are all default. Once the files are committed initially they're all set to read-only, not locked.

I think my problem is for other projects (not using SQL Source Control) the files are usually checked out which removes the read only status and that's why I've never had a problem before.

Nothing is set in the server's [auto-props] so read only must be default. Is there a setting to counteract this?
justin.collazo
 
Posts: 2
Joined: Fri Feb 26, 2010 11:17 pm

SVN needs-lock settings

Postby sherr » Tue Mar 02, 2010 12:50 pm

Hi Justin,

Thanks for checking the svn:needs-lock properties. We're looking into other settings to counteract this. Our internal reference number is SOC-719 and you should be hearing from us soon.
sherr
 
Posts: 126
Joined: Thu Mar 19, 2009 12:45 pm
Location: Cambridge

SVNSCC plug-in

Postby sherr » Wed Mar 03, 2010 7:09 pm

This issue was caused by a seperate SVN plug-in caused SVNSCC by Pushok Software. If you have this plug-in installed, use the following workaround:

To get SQL Source Control and SVNSCC to work together, we need to configure SVNSCC not to modify attributes on the check outs used by SQL Source Control. As far as I can tell, the best way to do this is:

1) Unlink all your SVN databases in SQL Source Control (Right click on each database, select 'Other SQL Source Control Tasks' then click 'Unlink database from source control.')
2) Close SSMS
2) Bring up a command prompt (Start+R, type in cmd and click ok)
3) Type or copy and paste in the line below changing <username> to be your windows login, and press enter

echo pushok::rwmon=skip-tree>"C:\\Users\\<username>\\AppData\\Local\\Red Gate\\.pushokprops"

4) Run the 'SSC RW Monitor' (under Start->All Programs->Pushok Software)
5) In the dialog that appears, click "Cleanup and Restart"
6) When it has finished processing, SQL Source Control should work (You will need to relink your databases)
sherr
 
Posts: 126
Joined: Thu Mar 19, 2009 12:45 pm
Location: Cambridge


Return to SQL Source Control EAP

Who is online

Users browsing this forum: No registered users and 0 guests