Access to Path XXXXX is denied - Can't check in data tables
maxfields2000
Posts: 4
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:
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:
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?
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?
Comments
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.
Redgate Software