SQL Source Control 7 - "The process cannot access the file"

neilpp

Every time I boot up SSMS and then run "Get Latest" I'm confronted by a "Tell Redgate about this error" modal.
It then says it cannot access a bin file in \AppData\Local\Red Gate\SQL Source Control 7\Caches\Scripts Folders 
because another process is using it. The files beginning with b and e are always those effected. I simply delete the files and then refresh and then the tool runs fine.

I'm running SQL v18.11.1 of SSMS and SQL Source Control version 7.3.10.14545 on Windows 10

This start occurring roughly a month back. My colleague who is using the same set-up is also having the same problem and for him it started roughly a fortnight earlier than it has for me.

Is this a bug in the latest version?

DanC

Hi @neilpp

I suspect this could be down to the anti-virus on your machines and it would be a good idea to exclude that folder path from being searched and used by the tool.

The latest version is also 7.3.29.15618 if you enable "frequent updates"

David_Thompson

Hi.

Myself and a number of colleagues started to see this issue earlier this week.

We have tried adding an exclusion in our anti-virus software with no success.

Running SQL Source Control 7 (Version 7.3.10.14545) No Updates Available.

I have attached my log file for reference.
Also tried tracing the event in Process Monitor and I found what appears to be the sharing violation.

Our work around at the moment is to delete the contents of "Scripts Folders" before opening SSMS. That seems to fix the issue. Until SSMS is restarted. At which point the issue comes back.

EDIT: Just want to confirm that opting in to frequent updates and upgrading to version 7.3.29.15618
seems to have fixed it for me.

We have some users running SQL Source Control 6 who may not benefit but this is an improvement.

JTankersley

The following works for me (until I restart SSMS)
1. Unlink from source control (SQL Source Control > Setup > Unlink from source control)
2. Link to source control (Link to source control > Just let me try it out > Use an existing evaluation repository > Link)

RobXE

Hi,

since a while, we have the same problem and it makes SQL Source Control hard to use.
It seems to work a short while after updates but reoccures.
I sent the error report without any response.

A fix of this issue is highly appreciated. Deleting the script folder on a regular basis should not be the final solution!

DanC

Hi @JTankersley @RobXE @David_Thompson and anyone experiencing this issue, you can use the following workaround:

Close SSMS, then go to %localappdata% > Red Gate > SQL Source Control 7 > Open the "RedGate_SQLSourceControl_Engine_EngineOptions" file in NotePadd++ or similar tool

Add the following lines and save the file

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<!---->

<EngineOptions version="3" type="EngineOptions">

  <MaxCacheSizeInMB>0</MaxCacheSizeInMB>

  <DisableCaching>True</DisableCaching>

</EngineOptions>

Please also delete the Caches folder from the same folder location, note this folder will still be created, but it will not be populated when using SQL Source Control and so this will stop any files being created and avoid this issue entirely.

Once you've added the lines of code and deleted the Cache folder, re-open SSMS and continue as normal

FredrikRN

Hi!

I just wanted to say that i upgraded to 7.3x and that sorted it for me. Before upgrade I tried reboot etc, but nothing helped.

So, try to upgrade first.

/Fredrik

JTankersley

Fixed for me also after upgrading to version 7.3

FredrikRN

FredrikRN said:

Hi!

I just wanted to say that i upgraded to 7.3x and that sorted it for me. Before upgrade I tried reboot etc, but nothing helped.

So, try to upgrade first.

/Fredrik

Well...problem is back.

I tried the suggestion from DanC and that works for me - so far. I will post back here if the problem comes back.

JTankersley

JTankersley said:

Fixed for me also after upgrading to version 7.3

The fix from DanC works for me (June 22, 2022 7:24AM).

twenzel

What are the ramifications of using DanC's fix and no longer having any cache? Does this affect the SQL Tab History? This issue has been a PITA for months now, and I was just deleting the Scripts folder every day, then I noticed all of my Tab History was gone - hence my question about that data too.

JTankersley

Not seeing negative ramifications of using DanC's fix.
And performance still good with Cache disabled with large databases.

mgrudem

We tried DanC's work-around by deleting the cache files and adding lines of code to end of EngineOptions file, but each day we seem to need to repeat that process and the EngineOptions reverts back to not having the added code at the bottom.  We are also using Source Control ver. 7.3 already.  Anyone else have this issue or any other ideas at a fix?

jhutchings

mgrudem said:

We tried DanC's work-around by deleting the cache files and adding lines of code to end of EngineOptions file, but each day we seem to need to repeat that process and the EngineOptions reverts back to not having the added code at the bottom.  We are also using Source Control ver. 7.3 already.  Anyone else have this issue or any other ideas at a fix?

This is happening to my team as well. We implement the workaround, and it stays that way for a day or two until it reverts the file to its original state. This issue is really inhibiting our ability to work with SQL Source Control. 

@DanC Any other ideas as to what is causing this? It doesnt appear to be AV related - exclusions added to AV for that path. The workaround is overwritten every other day. 

mgrudem

jhutchings said: This is happening to my team as well. We implement the workaround, and it stays that way for a day or two until it reverts the file to its original state. This issue is really inhibiting our ability to work with SQL Source Control. 

@DanC Any other ideas as to what is causing this? It doesnt appear to be AV related - exclusions added to AV for that path. The workaround is overwritten every other day. 

Just an update from my end: Through further troubleshooting, I determined when I disabled the ransomware component on the AV application (Sophos endpoint protection), the error ceased.  I added exclusions to the antivirus however for that component, but the error continues to occur.  

DanC

Hi @mgrudem

I would advise using something like Process Monitor to check what's taking control of the file