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

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?
Tagged:

Answers

  • 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"

    Kind regards

    Dan Calver | Redgate Software
    Have you visited our 
    Help Center?

  • David_ThompsonDavid_Thompson Posts: 1 New member
    edited May 20, 2022 11:47AM
    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.


  • JTankersleyJTankersley Posts: 5 New member
    edited May 25, 2022 4:35PM
    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)
  • RobXERobXE Posts: 1 New member
    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!

  • DanCDanC Posts: 630 Gold 5
    edited June 22, 2022 12:25PM
    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





    Kind regards

    Dan Calver | Redgate Software
    Have you visited our 
    Help Center?

  • FredrikRNFredrikRN Posts: 2 New member
    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
  • Fixed for me also after upgrading to version 7.3
  • FredrikRNFredrikRN Posts: 2 New member
    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.

  • JTankersleyJTankersley Posts: 5 New member
    Fixed for me also after upgrading to version 7.3
    The fix from DanC works for me (June 22, 2022 7:24AM).
  • twenzeltwenzel Posts: 6 Bronze 1
    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.
  • JTankersleyJTankersley Posts: 5 New member
    edited November 8, 2022 6:34PM
    Not seeing negative ramifications of using DanC's fix.
    And performance still good with Cache disabled with large databases.
  • mgrudemmgrudem Posts: 2 New member
    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?
  • jhutchingsjhutchings Posts: 3 New member
    edited November 17, 2022 4:15PM
    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. 
  • mgrudemmgrudem Posts: 2 New member
    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.  
  • Hi @mgrudem

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

    Kind regards

    Dan Calver | Redgate Software
    Have you visited our 
    Help Center?

Sign In or Register to comment.