Per MSDN Docs: http://msdn.microsoft.com/en-us/library/hh510202.aspx
LocalDB supports two kinds of instances: Automatic instances and Named instances.
I suspect this has something to do with my problem, so I am wondering if anyone knows how something like this gets automatically created. If I can quote from the docs, "One automatic instance of LocalDB exists for every version of LocalDB installed on the user’s computer."
Here is a copy of the relevant section in the above link:
Automatic instances of LocalDB are public. They are created and managed automatically for the user and can be used by any application.
One automatic instance of LocalDB exists for every version of LocalDB
installed on the user’s computer. Automatic instances of LocalDB
provide seamless instance management. There is no need to create the
instance; it just works. This allows for easy application installation
and migration to a different computer.
Different versions of LocalDB will have different instance naming conventions:
SQL 2012 LocalDB = V11.0
SQL 2014 LocalDB = ProjectsV12
I've seen others.
As long as the connecting app's connection string points to the correct instance, all is well:
(localdb)\V11.0
(localdb)\ProjectsV12
If I try to connect with SQL Server Management Studio to either instance (localdb)\V11.0 or (localdb)\ProjectsV12, I CAN, the "stopped" server "autostarts".
If I set the SQL Server instance in VS2013 to either instance (localdb)\V11.0 or (localdb)\ProjectsV12, I CANNOT, the "stopped" server "fails" to start. It attempts to start, but fails.
Here is the error message found in the instance error.log indicating why the instance start failed.
014-12-19 15:12:14.09 Logon Error: 17828, Severity: 20, State: 3.
2014-12-19 15:12:14.09 Logon The prelogin packet used to open the connection is structurally invalid; the connection has been closed. Please contact the vendor of the client library. [CLIENT: <named pipe>]
I may have found a clue here:
On one of my machines where Automatic Instancing works, the sqllocaldb command outputs following:
C:\>sqllocaldb info v11.0
Name: v11.0
Version: 11.0.3000.0
Shared name:
Owner: AM\Z617699
Auto-create: Yes <-- Yes? - and I have no idea how this is set.
State: Stopped
Last start time: 12/18/2014 5:18:46 PM
Instance pipe name:
On one of my other machines where Automatic Instancing does NOT work, the sqllocaldb command outputs following:
C:\>sqllocaldb info v11.0
Name: v11.0
Version: 11.0.3000.0
Shared name:
Owner: AM\Z617699
Auto-create: No <-- No? - and I have no idea how this is set.
State: Stopped
Last start time: 12/18/2014 5:18:46 PM
Instance pipe name:
I have spent days trying to find the answer to this question. Here is a link to an MSDN forum post that outlines all the unsuccessful steps I have taken to resolve this issue:
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/83ad45d5-15c3-4463-bc0c-6c4899bf947e/localdb-visual-studio-2013-will-not-automatically-start-the-sql-2014-localdb-projectsv12-instance?forum=sqlexpress
The workaround is to just start the instance manually before you start VS2013. I'm just trying to resolve this issue so I can get an "Automatic Instance" image for all our developers.
I hope you just know he answer. :-)
Thanks, Dave
I had the same issue.
I resolved it by deleting and recreating the instance from command line:
Open the command line
Delete the session by typing: sqllocaldb delete "v11.0"
Recreate the instance with: sqllocaldb create "v11.0"
The new instance allows auto creation, and solves the issue.
The solution was taken from:
http://answers.flyppdevportal.com/categories/sqlserver/sqlexpress.aspx?ID=8bcb5f1e-0240-4df3-8a5e-7e3e73e1c45b
I had the same problem on VS2015 and SQL2016
the problem my dev station is a laptop, project explorer i think uses tcpip connection, while SQLeplorer local file or so.
It worked after i made sure that SQL used the Network card, and that it had a cable plugged in (so SQL could server the request over TCP using that IP) which it couldnt over wifi (by default?)
I had the same problem. One of the problem may be an older installed version of this product. Try to delete the database instances which are located in the following folder:
C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Microsoft
SQL Server Local DB\Instances\VeeamEndPoint
After that it works for me!!!
Related
I am trying to create a default instance of SSMS to run through a few quick tutorials on my local machine. However, everything I am reading is telling me that this default instance should have been created during the wizard. Welp, I have now installed and uninstalled SSMS 2016 three times and am yet to be prompted by anything other than a simple request to install and a notification that the request is complete.
I have read online that I should use the SQL Server Management 2016 Application to create this instance, but every time I try to open that application I get this wonderful error "Cannot connect to WMI provider. You do not have permission or the server is unreachable".
I have tried running the command referenced in this article to fix the error:
https://support.microsoft.com/en-us/kb/956013
But had no luck.
I've also tried to attempt to connect to what might be the default value for the instance:
-localhost
-myip
-(local)
etc..
But when I ran osql -L earlier, it showed no SQL databases on my machine and since my most recent install this command isn't even working.
You dont create instances with SSMS. SQL Server Management Studio is to query and manage existing instances.
You use the Installation media to create an instance.
Look for the Configuration manager to see what instances you have installed.
The default instance is always called MSSQLSERVER.
According to the article you linked to, you probably jacked the installation between the 32 and 64 bit versions of SQL Server.
I suggest to use the setup program and reinstall it.
the cmd execution of registerRExt.exe
I am trying to install RRE(Revolution R Enterprise) v7.5 with RR0 3.2.2(Revolution R Open) on a SQL Server 2016 RC0 default instance. All the steps shown in the https://msdn.microsoft.com/en-us/library/mt590808.aspx have been completed and the error occurs in the Post installation Server configuration scripts. The script has also been replaced by the updated script for RC0 shown on the msdn site but still I get the same error on running the registerRExt.exe file.
The site shows while installing the instance the account name for Server Database engine has to be MSSQLSERVER, however this had also resulted in an error stating wait on database recovery handle failed which was sorted by changing the account name of Database engine to NT AUTHORITY/SYSTEM(I provided this info as it can also be the cause of the problem) . Now I need to sort the user pool failure. Any help would be appreciated..thanks in advance
SQL 2016 RC1 was just released https://blogs.technet.microsoft.com/dataplatforminsider/2016/03/18/sql-server-2016-release-candidate-1-now-available/.
SQL RC1 has a newer version 8.0.1 version of RRE. I suggest your try to install it and reply to this thread again if you hit the same failure. https://msdn.microsoft.com/library/mt590809.aspx has the details on where to find Microsoft R Open 8.0.1 and Revolution R Enterprise 8.0.1.
If the issue persists RevoScaleR\rxLibs\x64\registerrext.log would have more details on the exact failure - do share that.
I was able to sort out the issue..It was because I was installing the SQL server on domain controller and ignored the warning while install, but then changing some rules and demoting it from Server Manager worked and the install was successful.
However I do know there may be some better solution to that as all the other user accounts got reset in the process.
I have a very small test application in which I'm trying to install a Windows Service and create a LocalDB database during the install process, then connect to that LocalDB database when the Windows Service runs.
I am running into huge problems connecting to a LocalDB instance from my Windows Service.
My installation process is exactly like this:
Execute an installer .msi file which runs the msiexec process as the NT AUTHORITY\SYSTEM account.
Run a custom action to execute SqlLocalDB.exe with the following commands:
sqllocaldb.exe create MYINSTANCE
sqllocaldb.exe share MYINSTANCE MYINSTANCESHARE
sqllocaldb.exe start MYINSTANCE
Run a custom C# action using ADO.NET (System.Data.SqlConnection) to perform the following actions:
Connect to the following connection string, Data Source=(localdb)\MYINSTANCE; Integrated Security=true
CREATE DATABASE TestDB
USE TestDB
CREATE TABLE ...
Start the Windows Service before the installer finishes.
The Windows Service is installed to the LocalSystem account and so also runs as the NT AUTHORITY\SYSTEM user account.
The service attempts to connect using the same connection string used above.
I am consistently getting the following error when trying to open the connection to the above connection string from within the Windows Service:
System.Data.SqlClient.SqlException (0x80131904): A network-related or
instance-specific error occurred while establishing a connection to
SQL Server. The server was not found or was not accessible. Verify
that the instance name is correct and that SQL Server is configured to
allow remote connections. (provider: SQL Network Interfaces, error: 50
- Local Database Runtime error occurred. The specified LocalDB instance does not exist.
This is frustrating because both the msi installer custom action and the Windows Service are running under the same Windows user account (I checked, they're both NT AUTHORITY\System). So why the first works and the second does not is beyond me.
I have tried changing the connection strings used in the custom action and the Windows Service to use the share name (localdb)\.\MYINSTANCESHARE and I get the exact same error from the Windows Service.
I have tried changing the user account that the Windows Service logs on as to my Windows user account, which does work as long as I first run a command to add it to the SQL server logins for that instance.
I've also tried running a console application and connecting to the share name connection string and that works as well.
I've also tried connecting to the share name from SQL Server Management Studio and that works as well.
However none of these methods really solve my problem. I need a Windows Service because it starts up as soon as the computer starts up (even if no user logs on) and starts up no matter which user account is logged in.
How does a Windows Service connect to a LocalDB private instance?
I am using SQL Server 2014 Express LocalDB.
Picking up from the comments on the question, here are some areas to look at. Some of these have already been answered in those comments, but I am documenting here for others in case the info might be helpful.
Check here for a great source of info on SQL Server Express LocalDB:
SQL Server 2014 Express LocalDB
SqlClient Support for LocalDB
SqlLocalDB Utlity
Introducing LocalDB, an improved SQL Express (also look at the Q&A section at the end of the main post, just before the comments, as someone asked if LocalDB can be launched from a service, and the answer is:
LocalDB can be launched from a service, as long as the profile is loaded for the service account.
What version of .Net is being used? Here it is 4.5.1 (good) but earlier versions could not handle the preferred connection string (i.e. #"(localdb)\InstanceName"). The following quote is taken from the link noted above:
If your application uses a version of .NET before 4.0.2 you must connect directly to the named pipe of the LocalDB.
And according to the MSDN page for SqlConnection.ConnectionString:
Beginning in .NET Framework 4.5, you can also connect to a LocalDB database as follows:
server=(localdb)\\myInstance
Paths:
Instances: C:\Users{Windows Login}\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances
Databases:
Created via SSMS or direct connection: C:\Users{Windows Login}\Documents or C:\Users{Windows Login}
Created via Visual Studio: C:\Users{Windows Login}\AppData\Local\Microsoft\VisualStudio\SSDT
Initial Problem
Symptoms:
Database files (.mdf and .ldf) created in the expected location:
C:\Windows\System32\config\systemprofile
Instance files created in an unexpected location:
C:\Users\{current user}\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances
Cause (note taken from "SqlLocalDB Utility" MSDN page that is linked above; emphasis mine):
Operations other than start can only be performed on an instance belonging to currently logged in user.
Things to try:
Connection string that specifies the database (though maybe a long-shot if the error is regarding not being able to connect to the instance):
"Server=(LocalDB)\MYINSTANCE; Integrated Security=true ;AttachDbFileName=C:\Windows\System32\config\systemprofile\TestDB.mdf"
"Server=(LocalDB)\.\MYINSTANCESHARE; Integrated Security=true ;AttachDbFileName=C:\Windows\System32\config\systemprofile\TestDB.mdf"
Is the service running? Run the following from a Command Prompt:
TASKLIST /FI "IMAGENAME eq sqlservr.exe"
It should probably be listed under "Console" for the "Session Name" column
Run the following from a Command Prompt:
sqllocaldb.exe info MYINSTANCE
And verify that the value for "Owner" is correct. Is the value for "Shared name" what it should be? If not, the documentation states:
Only an administrator on the computer can create a shared instance of LocalDB
As part of the setup, add the NT AUTHORITY\System account as a Login to the system, which is required if this account is not showing as the "Owner" of the instance:
CREATE LOGIN [NT AUTHORITY\System] FROM WINDOWS;
ALTER SERVER ROLE [sysadmin] ADD MEMBER [NT AUTHORITY\System];
Check the following file for clues / details:
C:\Users{Windows Login}\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\MYINSTANCE\error.log
In the end you might need to create an actual account to create and own the Instance and Database, as well as run your service. LocalDB really is meant to be user-mode, and is there any downside to having your service have its own login? And you probably wouldn't need to share the instance at that point.
And in fact, as noted by Microsoft on the SQL Server YYYY Express LocalDB MSDN page:
An instance of LocalDB owned by the built-in accounts such as NT AUTHORITY\SYSTEM can have manageability issues due to windows file system redirection; Instead use a normal windows account as the owner.
UPDATE (2015-08-21)
Based on feedback from the O.P. that using a regular User account can be problematic in certain environments, AND keeping in mind the original issue of the LocalDB instance being created in the %LOCALAPPDATA% folder for the user running the installer (and not the %LOCALAPPDATA% folder for NT AUTHORITY\System ), I found a solution that seems to keep with the intent of easy installation (no user to create) and should not require needing extra code to load the SYSTEM profile.
Try using one of the two built-in accounts that is not the LocalSystem account (which does not maintain its own registry info. Use either:
NT AUTHORITY\LocalService
NT AUTHORITY\NetworkService
Both have their profile folders in: C:\Windows\ServiceProfiles
While I have not been able to test via an installer, I did test a service logging on as NT AUTHORITY\NetworkService by setting my SQL Server Express 2014 instance to log on as this account, and restarted the SQL Server service. I then ran the following:
EXEC xp_cmdshell 'sqllocaldb c MyTestInstance -s';
and it created the instance in: C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances
I then ran the following:
EXEC xp_cmdshell N'SQLCMD -S (localdb)\MyTestInstance -E -Q "CREATE DATABASE [MyTestDB];"';
and it had created the database in: C:\Windows\ServiceProfiles\NetworkService
I was able to solve similar issue in our WiX installer recently. We have a Windows service, running under SYSTEM account, and an installer, where LocalDB-based storage is one of the options for database configuration. For some time (a couple of years actually) product upgrades and service worked quite fine, with no issues related to LocalDB. We are using default v11.0 instance, which is created in SYSTEM profile in C:\Windows\System32\config tree, and a database specified via AttachDbFileName, created in ALLUSERSPROFILE tree. DB provider is configured to use Windows authentication. We also have a custom action in installer, scheduled as deferred/non-impersonate, which runs DB schema updates.
All this worked fine until recently. After another bunch of DB updates, our new release started to fail after having upgraded over the former - service was unable to start, reporting infamous "A network-related or instance-specific error occurred while establishing a connection to SQL Server" (error 50) fault.
When investigating this issue, it became apparent that the problem is in a way WiX runs custom actions. Although non-impersonated CA-s run under SYSTEM account, the registry profile and environment remain that of current user (I suspect WiX loads these voluntary when attaching to user's session). This leads to incorrect path being expanded from the LOCALAPPDATA variable - the service receives SYSTEM profile one, but the schema update CA works with the user's one.
So here are two possible solutions. The first one is simple, but too intrusive to user's system - with cmd.exe started via psexec, recreate broken instance under the SYSTEM account. This was not an option for us as the user may have other databases created in v11.0 instance, which is public. The second option assumed lots of refactoring, but wouldn't hurt anything. Here is what to do to run DB schema updates properly with LocalDB in WiX CA:
Configure your CA as deferred/non-impersonate (should run under SYSTEM account);
Fix environment to point to SYSTEM profile paths:
var systemRoot = Environment.GetEnvironmentVariable("SystemRoot");
Environment.SetEnvironmentVariable("USERPROFILE", String.Format(#"{0}\System32\config\systemprofile", systemRoot));
Environment.SetEnvironmentVariable("APPDATA", String.Format(#"{0}\System32\config\systemprofile\AppData\Roaming", systemRoot));
Environment.SetEnvironmentVariable("LOCALAPPDATA", String.Format(#"{0}\System32\config\systemprofile\AppData\Local", systemRoot));
Environment.SetEnvironmentVariable("HOMEPATH", String.Empty);
Environment.SetEnvironmentVariable("USERNAME", Environment.UserName);
Load SYSTEM account profile. I used LogonUser/LoadUserProfile native API methods, as following:
[DllImport("advapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
[return: MarshalAs(UnmanagedType.Bool)]
private static extern bool LogonUser(
string lpszUserName,
string lpszDomain,
string lpszPassword,
int dwLogonType,
int dwLogonProvider,
ref IntPtr phToken);
[StructLayout(LayoutKind.Sequential)]
struct PROFILEINFO
{
public int dwSize;
public int dwFlags;
[MarshalAs(UnmanagedType.LPWStr)]
public String lpUserName;
[MarshalAs(UnmanagedType.LPWStr)]
public String lpProfilePath;
[MarshalAs(UnmanagedType.LPWStr)]
public String lpDefaultPath;
[MarshalAs(UnmanagedType.LPWStr)]
public String lpServerName;
[MarshalAs(UnmanagedType.LPWStr)]
public String lpPolicyPath;
public IntPtr hProfile;
}
[DllImport("userenv.dll", SetLastError = true, CharSet = CharSet.Unicode)]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool LoadUserProfile(IntPtr hToken, ref PROFILEINFO lpProfileInfo);
var hToken = IntPtr.Zero;
var hProfile = IntPtr.Zero;
bool result = LogonUser("SYSTEM", "NT AUTHORITY", String.Empty, 3 /* LOGON32_LOGON_SERVICE */, 0 /* LOGON32_PROVIDER_DEFAULT */, ref token);
if (result)
{
var profileInfo = new PROFILEINFO();
profileInfo.dwSize = Marshal.SizeOf(profileInfo);
profileInfo.lpUserName = #"NT AUTHORITY\SYSTEM";
if (LoadUserProfile(token, ref profileInfo))
hProfile = profileInfo.hProfile;
}
Wrap this in an IDisposable class, and use with a using statement to build a context.
The most important - refactor your code to perform necessary DB updates in a child process. This could be a simple exe-wrapper over your installer DLL, or stand-alone utility, if your already have one.
P.S. All these difficulties could be avoided, if only Microsoft let uses choose where to create LocalDB instances, via command line option. Like Postgres' initdb/pg_ctl utilities have, for example.
I suggest using a different user account, and not using the System account, by doing the following:-
create a new account on the machine, and set that to be the account
under which the Windows Service runs. It's not good practice to use
the system account just to run an application, anyway, as the
permissions are excessive.
ensure that the permissions on the LocalDB files are set to allow the said user account to access the database (and thus continue to
use Integrated Security)
make sure it works by trying to connect to the DB (once installed) under the same user account by running sqlcmd or Management Studio
under the context of the said user, then connecting with Integrated
Security to ensure it works.
Some other things to try/consider:
have you checked the Windows Event log for any events that might be useful for diagnostic purposes?
Make sure that if you have any other versions of SQL Server (especially prior to 2012) that for the command-line tools, the %PATH% isn't set to find an older tools version first. Older tools don't support LocalDB.
It is possible also (as an alternative) to set up LocalDB to be shared with other users. This involves sharing the instance, and then granting access to other users. See the "Sharing Issues" section in this article: Troubleshoot SQL Server 2012 Express LocalDB.
There's also another SO article that may contain some more useful information there in the links within (change the language in the URL from Polish to English by changing pl-pl to en-us). His work-around is using SQL Server accounts, which might not be OK in your case.
This might also be useful, as it relates to security permissions being denied, and possible resolutions: https://dba.stackexchange.com/questions/30383/cannot-start-sqllocaldb-instance-with-my-windows-account
Trevor, the problem you have is with the MSI custom actions. You must configure them with "Impersonate=false" otherwise the custom actions will be executed under the current user context.
BTW what tool are you using to create the installer?
Depending on the tool you use, could you please provide screenshots or code snippets of your custom actions configuration?
The accepted answer from this post will give you some additional information about the different custom action execution alternatives:
Run ExeCommand in customAction as Administrator mode in Wix Installer
You will find additional information about impersonation here:
http://blogs.msdn.com/b/rflaming/archive/2006/09/23/768248.aspx
I wouldn't create the database under the system's localdb instance. I'd create it under the current user installing the product. This will make life much easier if you need to delete or manage the database. They can do this through sql management studio. Otherwise, you'll have to use psexc or something else to launch a process under the SYSTEM account to manage it.
Once the db is created, then use the share option you mentioned. The SYSTEM account can then access the database through the share name.
sqllocaldb share MSSqlLocalDb LOCAL_DB
When sharing, I've noticed you'll have to restart the the local db instance to actually access the db through the share name:
sqllocaldb stop MSSQLLocalDB
sqllocaldb start MSSQLLocalDB
Also, You may need to add the SYSTEM account as a db reader and writer to the database ...
EXEC sp_addrolemember db_datareader, 'NT AUTHORITY\SYSTEM'
Cannot start LocalDB instance, I have installed and re-installed over and over.
Keep getting this error :
Start of LocalDB instance "v11.0" failed because of the following error:
Error occurred during LocalDB instance startup: SQL Server process failed to start.
Anyone any advice ? ?
Microsoft SQL Server 2012, i have ensured the FULL installation options, stopped all services SQL related and tried restarting .
sqllocaldb info
gives me :
Projects
v11.0
when i try
sqllocaldb start v11.0
I get the above error.
When all else fails and you don't care about data loss, delete and recreate your LocalDB\v11.0 database! At the command prompt
sqllocaldb delete v11.0
sqllocaldb create v11.0
(Sqllocaldb is in your PATH right? It was for me.)
I was getting a similar error, but when running
sqllocaldb start
The local db started successfully. Also when checking the event log I saw an error along the lines of
Windows API call WaitForMultipleObjects returned error code: 575
What fixed it for me:
In IIS, configure the app pool to run under an account with permissions to the DB on the server (advanced options of the app pool)
In the advanced option of the app pool, set Load User Profile to true
Reference: http://blogs.msdn.com/b/sqlexpress/archive/2011/12/09/using-localdb-with-full-iis-part-1-user-profile.aspx
It worths looking at LocalDB log files too, it is more detailed than event log:
%LocalAppData%\Microsoft\Microsoft SQL Server Local DB\Instances\ProjectsV12\error.log
Besides recreating the instance I had to delete the content of this folder:
%LocalAppData%\Microsoft\VisualStudio\SSDT\
This is where I have the mdf and ldf files.
My solution:
Go to: %LocalAppData%\Microsoft\Microsoft SQL Server Local DB\ and allow total control of the folder "Instances" to everyone group.
I know this is not OK but it solved my problem and i don't really care about the data of that folder as this is a developing and testing computer.
Same problem here. Here's how I fixed it using bits of the other solutions posted here.
I had dozens of these errors in the application event log:
Windows API call WaitForMultipleObjects returned error code: 575. Windows system error message is: {Application Error}
The application was unable to start correctly (0x%lx). Click OK to close the application.
Reported at line: 3730.
I realized that I had SQL Server Management Studio installed on my development machine, but no other SQL components. I installed the database engine, shared components, and localdb from SQL Express
https://www.microsoft.com/en-us/cloud-platform/sql-server-editions-express
After installing, I still get the same error in event log :(
Found this article:
Cannot start LocalDB
Run the following in cmd to get the localdb instance name:
C:> sqllocaldb info
In my install, I had:
MSSQLLocalDB
ProjectsV13
I ran the following to delete the instances:
sqllocaldb delete MSSQLLocalDB
sqllocaldb delete ProjectsV13
I ran into issues trying to delete/create these (sqllocaldb delete MSSQLLocalDB). I ended up deleting all of the folders and files under '%LocalAppData%\Microsoft\Microsoft SQL Server Local DB\Instances*' (You need to stop SQL Server and kill all sqlserver processes)
Then running 'sqllocaldb create' created and started the default instance and all files.
Had this issue suddenly too but saw nothing weird in logs. Was able to get it running by running the following in an administrator command prompt:
sqllocaldb start
I had this issue. I was trying to use Windows Authentication through an application, but the IIS App Pool credentials were wrong. I was using my Windows user name (ie: NETWORK\name) as my identity, but I changed it to the built-in "LocalSystem" and it worked.
You should check the Event Log for additional information.
Product Name
SQL Server
Product Version
11.0
Product Build Number
Event ID
266
Event Source
SQL Server Local Database Runtime 11.0
Component
Local Database Runtime API
Message Text
Error occurred during Local Database instance startup: SQL Server
process failed to start.
Explanation
A SQL Server process is started but SQL Server startup failed.
User Action
See the event log for details.
Source: http://msdn.microsoft.com/en-us/library/hh256140.aspx
What worked for me was the local IIS application pool I was using was the ApplicationPoolIdentity and that did not have permission to login to MSSQLLocalDB. As soon as a I changed the app pool identity to my windows login account - I was able to connect ok.
Had this issue on Windows 10 when our application was run with compatibility for Windows 8 enabled. Turning off the compatibility setting fixed it.
Before you try something drastic:
After waiting for about 5 minutes it "healed" itself.
(May be this is what this log message is pointing at: "The RANU instance is terminating in response to its internal time out")
I can not yet comment posts here but I really want to give a hint for the in my case extremely helpful post https://stackoverflow.com/a/30298863/8015089 above:
If your LocalDB instance is run by the Windows SYSTEM user (as in my case) the path to error.log is this (MS SQL Server 2012 Express LocalDB on Win11): C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\<InstanceName> (enter this path subfolder by subfolder to avoid access problems!)
I built an application for a client that requires SQL Server 2005 Express. Everything worked fine on all the machines except for one. On this one they already had an application that uses SQL Server Express, so it was already installed on the machine, but nobody knows which application uses it or any usernames/passwords.
Can I simply install another copy into a different folder? This just doesn't seem right to me, and I know this has to be a common scenario. Can someone point me in the right direction on how I should proceed?
Thanks!
Darvis
Yes you can just install into a different directory, as a new "named instance" of SQL Server Express.
To install, follow Step 8 on Microsoft's Install How-To:
On the Instance Name page, select a Default instance or a Named instance for your installation. If you select Default instance, an existing default instance will be upgraded. If you select Named Instance, specify an instance name
So what you need to do is specify the Named Instance and specify your own instance name, and connect to it using the URL format as above.
As the Microsoft How-To mentions, the default installation is a named instance as well, with the name "SQLExpress", which is why if you want to stop or start the service with net start or `net stop' you need to write something like:
net start mssql$sqlexpress
and the hostname part of the connection string for a default SQL named instance is:
.\SQLEXPRESS (or localhost\SQLEXPRESS)
You should be able to log into it using Integrated Windows Authentication using an administrator type account on the PC, and use that to reset passwords on any SQL server type logins.
Failing that, yes, you should be able install a "named instance". You connect to it by supplying "hostname\instancename" as the server name.
In all likelihood, the culprit is Outlook's Contact Manager.
You should just uninstall the "feature". If you can't, you can create an additional instance of SQL Express, which you can access as COMPUTERNAME\INSTANCENAME.