Options
LocalDB DB linking lost when Management Studio crashes?
MDJ
Posts: 4 New member
We are evaluating SQL Source Control and I am testing it using some DBs created in localDB (v11.0).
So far everything works great and I have moved on to some more advanced use cases for our development teams but I am having one issue.
The SQL Source Control DB links are lost whenever SQL Management Studio crashes on me (happens semi-regularly due to system instability related to some corporate "security" bloatware [aka out of my control]).
I cannot reproduce this on demand. If I close Management studio or even reboot the machine all is good once I open it back up.
If my PC crashes (or SLQ MS itself crashes) the links are gone once I reopen and I have to relink everything (6 DBs at this stage of testing).
Where is the linking stored? I have seen a reference to a DB named RedGateTemp but I do not see that in my localDB instance.
Any help would be appreciated as I am running out of time on my trial license.
Also when this happens the old SVN folders under WorkingBases, Transients, MigrationsFolderWorkingBases, MigrationsFolderLiveInstances keep accumulating (taking up unnecessary space) it would be nice if there was a tool to clean these up.
-Mark j
So far everything works great and I have moved on to some more advanced use cases for our development teams but I am having one issue.
The SQL Source Control DB links are lost whenever SQL Management Studio crashes on me (happens semi-regularly due to system instability related to some corporate "security" bloatware [aka out of my control]).
I cannot reproduce this on demand. If I close Management studio or even reboot the machine all is good once I open it back up.
If my PC crashes (or SLQ MS itself crashes) the links are gone once I reopen and I have to relink everything (6 DBs at this stage of testing).
Where is the linking stored? I have seen a reference to a DB named RedGateTemp but I do not see that in my localDB instance.
Any help would be appreciated as I am running out of time on my trial license.
Also when this happens the old SVN folders under WorkingBases, Transients, MigrationsFolderWorkingBases, MigrationsFolderLiveInstances keep accumulating (taking up unnecessary space) it would be nice if there was a tool to clean these up.
-Mark j
Tagged:
Comments
Thanks for your post.
Information about linked databases is stored in "C:Users(username)AppdataLocalRed GateSQL Source Control 4LinkedDatabases.xml".
We've also opened an incident in our support system, so that we can determine what's causing the databases to unling when SSMS crashes.
Thank you,
Product Support Engineer
Redgate Software Ltd
Please see our Help Center for detailed guides on how to use our tools
I cannot manually reproduce this issue by killing the SSMS process.
It has happened once when SSMS crashed for an unknown reason while not working within SQL Source Control.
It has also happened numerous times when my machine has restarted (unexpectedly) while I was away (maybe caused by my corporate IT upgrade policy but probably not as they usually occur in the evenings).
I will check out the LinkedDatabases.xml file the next time it happens and report back.
Thanks for the attention.
-Mark j
Looking at the LinkedDatabases.xml file I think I see the problem.
I actually have multiple instances for the DBs in question. Each has a slightly different value for ServerAndInstanceName.
A few examples:
<computer name>LOCALDB#05AC19B8
<computer name>LOCALDB#F0CCDDFC
<computer name>LOCALDB#315412F2
My guess is that the SQL instance name changes when the LocalDB server starts / restarts.
I normally sleep or hibernate my machine so the instance name wouldn't change unless it was actually shut down.
My actual instance name is a human readable name ("v11.0"). I also tested with an instance name of "UserTest" and LocalDB still returns the LOCALDB#XXXXXXXX instance name from SELECT SERVERPROPERTY('InstanceName'). I connect to them using the format "(localdb)<instance name>" (localdb)UserTest so I'm not sure why the actual instance name is the non human readable name.
I am not sure if there is anything you can about it at this point, that is part of how you track the DB instance (rightfully so). I may switch to SQL express as I do not think it behaves like this.
You are right the instance name change is the cause as that's how SQL Source Control tracks linked databases.
You won't have that issue if you use SQL Server Express.
Thank you,
Product Support Engineer
Redgate Software Ltd
Please see our Help Center for detailed guides on how to use our tools
This looks like a question that one of Support engineers will need to investigate for you.
If you've a got support contract, please send us a ticket. Provide as much information as you can - screenshots of any errors, log files etc – so we can help you as fast as possible.
If you're not covered by a Support contract at the moment, email our Sales team at sales@red-gate.com, and they'll be able to help.
Redgate Software