Access to Path XXXXX is denied - Can't check in data tables

A SQL Server Management Studio add-in to source control your database in Subversion or Team Foundation Server.

Moderators: Chris Auckland, David Atkinson, sherr, PhilScrace

Access to Path XXXXX is denied - Can't check in data tables

Postby maxfields2000 » Fri Nov 04, 2011 8:02 am

I'm using perforce for source control, I have a database with many static data tables. Over time SQL Source Control has steadily increased it's "error" when trying to check in data changes. Typically it throws the following error:

Access to the path 'D:\\xxx\\xxx\\xxx\\xxx\\Data\\dbo.TableName_Data.sql' is denied.


I can often "resolve" this issue by changing the read only flag on the file to writeable. At which point SQL Source Control happily checks the file in.

However there are times where even that doesn't work. When that fails I get the following error:

The list of changes to commit was out of date, so the commit was refused by...



At this point I have no visible way to solve this problem short of un-linking the data table, marking the file for delete from perforce, then relink the table and re check the table in. It's frustrating, pointless and makes me think I'm doing something wrong.

This has plagued me between the most recent version and previous version of SQL Source control and I really need this fixed. Any ideas?
maxfields2000
 
Posts: 2
Joined: Sat May 07, 2011 1:39 am

Postby james.billings » Mon Nov 07, 2011 3:49 pm

Thanks for you post regarding SQL Source Control.

Whenever we've seen this kind of "access denied" message before, it's been when something else has a lock on the file which stops SQL Source Control updating it. The most common cause is if your anti-virus software is set to perform "on access" or "realtime" scanning. If so, I'd suggest excluding the folder structure from that. In addition, I'd exclude the working copies that SQL Source Control also uses (i.e. "c:\\users\\<your username>\\appdata\\local\\red gate\\sql source control x", where "x" is the source control version number)

Other less common causes are Windows Search Indexing, or background file-backup tools; again, it's worth excluding all the relevant folders from these operations.

If that doesn't help, let us know, and we'll see what other troubleshooting steps can be taken.
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.


Return to SQL Source Control 2

Who is online

Users browsing this forum: No registered users and 0 guests