I think something happened to an mdf file on disk.
When I try to start SQL Server Mgmt Studio (SQL Server 2008, Win 7 x64), I get an error:
"Cannot open user default database."
Since I can't connect at all, how do I fix this?
I have tried connecting to other dbs using osql, but always get an error.
Thanks for any workarounds...
The easiest way to do this is via command line. You keep opening connections using SSMS that fail...
Using command line you'll have one connection and delimit the login name correctly: "[SVR\USR]"
sqlcmd -S InstanceName -d master -E -Q"ALTER LOGIN [SVR\USR] WITH DEFAULT_DATABASE = master"
or replace -E with -U SQLLogin -P Password if you have a SQL login handy
When connecting from Management studio, In the "connect to server" dialog box, before connecting, click "Options" and change the "Connect to database" dialog box to "master".
Login as an administrator and change your default database: ALTER LOGIN ... WITH DEFAULT_DATABASE = .... If you're not an administrator, ask an administrator to do it. If you must log in in the database in question, ask an administrator to investigate whi the database is offline.
Related
Using SQL Server 2016 (localdb)\ProjectsV13, I created a database - let's call it MyDatabase. All was fine and dandy until I decided I no longer needed it...
So in SSMS 2016, while connected to (localdb)\ProjectsV13, I right clicked on MyDatabase and clicked "Delete".
Now when I try to establish a connection to (localdb)\ProjectsV13, it fails.
Here's the error message:
Cannot connect to (localdb)\ProjectsV13.
Cannot open database "MyDatabase" requested by the login. The login failed. Login failed for user 'MyDomain\MyUserName'. (Microsoft SQL Server, Error: 4060)
So even though I deleted the MyDatabase database (I know - I should of just run a DROP), SSMS is still trying to connect to MyDatabase which of course fails and then prevents me from connecting to (localdb)\ProjectsV13 at all - which is the real issue.
How can I resolve this so that SSMS doesn't try to connect to the deleted MyDatabase database when connecting to (localdb)\ProjectsV13?
Like Sean suggested, I think your default database is the problem. If you're using visual studio, right-click the server and click on the properties option. You'd see a 'Default Database Location' property. Alter the value.
If you're not using visual studio, then change your default database or check that your connection string does not attach the deleted database when you connect. E.g.
connectionString="Data Source=(LocalDB)\MSSQLLocalDB;AttachDbFilename=D:\StaffLoginSystem.mdf;Integrated Security=True;Connect Timeout=30"
Check the value of 'AttachDbFilename' property and edit accordingly.
A Database Server has been cloned. The Operating System is "Microsoft Windows XP Professional Version 2002 Service Pack 3". The Query Environment is "Microsoft SQL Server 2008 Management Studio 10.0.4000.0".
After cloning, the following behaviour has been noticed. While attempting to connect from outside the machine, yet within the same domain, the following error message can be read: "Cannot generate SSPI context. (.Net SqlClient Data Provider)".
From within the machine, it is possible to connect to the Database Server using the "Microsoft SQL Server 2008 Management Studio" Query Environment.
However, when attempting to run the SQLCmd command line tool, the following error is displayed:
C:\<Directory>>SQLCmd -S DBA2\<Instance> -i C:\<Directory>\<FileName>.SQL
HResult 0x80090322, Level 16, State 1
SQL Server Network Interfaces: The target principal name is incorrect.
Sqlcmd: Error: Microsoft SQL Server Native Client 10.0 : Cannot generate SSPI context.
The ServicePrincipalNames are set the following way:
C:\PROGRA~1\SUPPOR~1>setspn DBA2
Registered ServicePrincipalNames for CN=DBA2,CN=Computers,DC=<Company>,DC=com:
VProRecovery Backup Exec System Recovery Agent 7.0/DBA2.<Company>.com
HOST/DBA2
HOST/DBA2.<Company>.com
While running the "C:\PROGRA~1\SUPPOR~1\ADSIEDIT.MSC" Support Tool from the Microsoft Windows XP Professional compact disk, we can see below the "ADSI Edit \ Domain [<Site>.<Company>.com] \ DC=<Company>,DC=com" path the "CN=Computers" leaf. In its "Properties" dialog box, inside the "Security" tab, below the "Group or user names:" list, there is the "SELF" entry. On pressing the "Advanced" button, the "Advanced Security Settings for Computers" dialog box is generated. On the "Permissions" tab, under the "Permission entries:" list, there also is an entry with the Name "SELF". By pressing the "Edit..." button, the "Permission Entry for Computers" dialog box is displayed. On its "Properties" tab, in the "Permissions:" list, there are no entries for the "Read ServicePrincipalName" permission and for the "Write ServicePrincipalName" permission.
This might be the reason why the following command fails:
C:\PROGRA~1\SUPPOR~1>setspn -r DBA2
Registering ServicePrincipalNames for CN=DBA2,CN=Computers,DC=<Company>,DC=com
HOST/DBA2.<Company>
HOST/DBA2
Failed to assign SPN to account 'CN=DBA2,CN=Computers,DC=<Company>,DC=com', 0x2098
Even if there were permissions in place for resetting the ServicePrincipalName on the cloned Database Server, would that solve the connection both from SQLCmd and from outside the machine, within the same domain?
Actually, yes, that solved the problem after the right permissions were set in the right place.
The ServicePrincipalNames had to be set on the SQL user, as follows:
C:\PROGRA~1\SUPPOR~1>setspn -a mssqlsvc/dba2:1433 <Company>\<UserName>
Registering ServicePrincipalNames for CN=<UserName>,OU=Reporting Security,OU=Security Groups,OU=Romania,DC=<Company>,DC=com
mssqlsvc/dba2:1433
Updated object
C:\PROGRA~1\SUPPOR~1>setspn -a mssqlsvc/dba2.<Company>.com:1433 <Company>\<UserName>
Registering ServicePrincipalNames for CN=<UserName>,OU=Reporting Security,OU=Security Groups,OU=Romania,DC=<Company>,DC=com
mssqlsvc/dba2.<Company>.com:1433
Updated object
C:\PROGRA~1\SUPPOR~1>setspn -l dba2
Registered ServicePrincipalNames for CN=DBA2,OU=Romania Machines,OU=Romania,DC=<Company>,DC=com:
VProRecovery Backup Exec System Recovery Agent 7.0/DBA2.<Company>.com
HOST/DBA2
HOST/DBA2.<Company>.com
C:\PROGRA~1\SUPPOR~1>setspn -l <UserName>
Registered ServicePrincipalNames for CN=<UserName>,OU=Reporting Security,OU=Security Groups,OU=Romania,DC=<Company>,DC=com:
MSSQLSvc/DBA2.<Company>.com:<Company>_RO
mssqlsvc/dba2.<Company>.com:1433
mssqlsvc/dba2:1433
Hopefully this might help somebody who could stumble into the same problem.
We have some deployment scripts that use a combination of dacpacs through sqlpackage and straight scripts using sqlcmd.
When I execute the sqlpackage dac\sqlpackage.exe /p:BlockOnPossibleDataLoss=False /p:BackupDatabaseBeforeChanges=True /a:Publish /sf:.\somedeploy.dacpac /tcs:"Data Source=MyDB;Initial Catalog=MyCatalog;Trusted_Connection=True;"
I get an error message *** Could not deploy package. Unable to connect to target server. I have login auditing turned on in sql and the message I am getting is Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 111.222.223.224]
However, I can run our sql scripts through sqlcmd no problem by using the -E argument.
sqlcmd -i Permissions\CreateSqlUser.sql -S MyDB -E
I am running from a commandline that is set to "Run As Administrator" and am currently signed in as the admin. This is running on a Windows Server 2012 VM. I am using sql 2014. We have other installs that haven't had problems but this is our first 2014 install so we are trying to determine if something changed or if we are missing something and if so what.
If I run from profiler I don't see any audit log error messages. I checked the filters and what events I'm listening for and they all look good. Inside sql when I run exec sys.sp_readerrorlog 0, 1, 'Login Failed' I do get the messgaes to show up. (I might be doign something wrong in profiler). Also they show up in the system event logs. I'm not seeing anyplace where it tells me anything about the user attempting to login though.
If don't use trusted connection for sqlpackage and instead use a username and password it works fine. However, part of what our deployment script does is create the users so our preference would be to not do this.
I have my SQLServer 2005 Standard instance configured for mixed mode fine. When using SSMS, none of the sql server logins seem to work. Just "Login failed for user '..'" message. But when I use SQLCMD, it works fine. The behavior is not just for one specific login account. All sql server logins including 'sa' fail when tried via SSMS. Windows logins work fine.
Any ideas?
EDIT1:
When connecting via SQLCMD, I do not specify the -S option. Just the -U and -P
Whereas in SSMS, Server name defaults to the machine name.
In SSMS the server seems to be registered as say xxxxN. When I connect using windows authentication, my ##servername returns xxxx_N.
When I try to use the xxxx_N in SSMS it fails to connect altogether.
Edit2:
When trying via SQLCMD if I give the -S option as xxxxN, it works fine too.
Edit3:
My SQLCMD:
C:...>SQLCMD -U sa -P Password (works)
C:...>SQLCMD -S xxxxN -U sa -P Password (works)
C:...>SQLCMD -U test -P Password (works)
C:...>SQLCMD -S xxxxN -U test -P Password (works)
in SSMS:
ServerType: Database Engine
ServerName: xxxxN
AUthentication: Windows Authentication (works)
ServerType: Database Engine
ServerName: xxxxN
AUthentication: Sql Server Authentication
Login: sa
Password: Password (fail)
ServerType: Database Engine
ServerName: xxxxN
AUthentication: Sql Server Authentication
Login: test
Password: Password (fail)
EDIT 4(Answer)
ODBC connections using sql accounts seem to work fine.
SSMS connections from remote machines work fine also.
This HAS TO BE an issue with local SSMS install. I believe a reinstall would fix this..
Your server/instance name is not consistent between the two.
MyMachineName\Express
is the "most common" instance name.
But yours may vary.
Since sqlcmd "works".
Run sqlcmd, and pass it this command
select [MyServerAndMaybeInstanceName] = ##servername
Then you will know what to put into SSMS ! (ta da!)
EDIT:
You say in sqlcmd, you give it
-U and -P
thus you're using Sql Authentication. (and not windows authentication)
Are you providing Sql Authentication credentials when trying through SSMS ?
I see you said "All sql server logins including 'sa' "
thus you are trying Sql Authentication credentials.
Can you just verify you've tried some Sql Authentication creditials, maybe something besides sa.
EDIT:
Here is a guess, but I hit it one time, a long time ago.
In the SSMS connection box, click "Connection Properties"
Find "Network".
And pick TCP/IP as the network protocol.
especially if the machine is a remote machine.
EDIT:
Here is another poor man's test.
Go to Control Panel /Admin Tools / Data Source (ODBC) / System DSN. And try to add a connection there.
You can also play with the protocols there (named-pipes vs tcp/ip, etc) with the "Client Configuration" button in the Wizard.
I have installed SQL Server 2008 express and logging in through windows authentication, it doesn't allow me to do anything. How do i change 'sa' password or gain full privilege in my local computers 2008 express ? I am using windows 7.
If you want to change your 'sa' password with SQL Server Management Studio, here are the steps:
Login using Windows Authentication and ".\SQLExpress" as Server Name
Change server authentication mode - Right click on root, choose Properties, from Security tab select "SQL Server and Windows Authentication mode", click OK
Set sa password - Navigate to Security > Logins > sa, right click on it, choose Properties, from General tab set the Password (don't close the window)
Grant permission - Go to Status tab, make sure the Grant and Enabled radiobuttons are chosen, click OK
Restart SQLEXPRESS service from your local services (Window+R > services.msc)
You need to follow the steps described in Troubleshooting: Connecting to SQL Server When System Administrators Are Locked Out and add your own Windows user as a member of sysadmin:
shutdown MSSQL$EXPRESS service (or whatever the name of your SQL Express service is)
start add the -m and -f startup parameters (or you can start sqlservr.exe -c -sEXPRESS -m -f from console)
connect to DAC: sqlcmd -E -A -S .\EXPRESS or from SSMS use admin:.\EXPRESS
run create login [machinename\username] from windows to create your Windows login in SQL
run sp_addsrvrolemember 'machinename\username', 'sysadmin'; to make urself sysadmin member
restart service w/o the -m -f
I didn't know the existing sa password so this is what I did:
Open Services in Control Panel
Find the "SQL Server (SQLEXPRESS)" entry and select properties
Stop the service
Enter "-m" at the beginning of the "Start parameters" fields. If there are other parameters there already add a semi-colon after -m;
Start the service
Open a Command Prompt
Enter the command:
osql -S YourPcName\SQLEXPRESS -E
(change YourPcName to whatever your PC is called).
At the prompt type the following commands:
alter login sa enable
go
sp_password NULL,'new_password','sa'
go
quit
Stop the "SQL Server (SQLEXPRESS)" service
Remove the "-m" from the Start parameters field
Start the service
This may help you to reset your sa password for SQL 2008 and 2012
EXEC sp_password NULL, 'yourpassword', 'sa'
This is what worked for me:
Close all Sql Server referencing apps.
Open Services in Control Panel.
Find the "SQL Server (SQLEXPRESS)" entry and select properties.
Stop the service (all Sql Server services).
Enter "-m" at the Start parameters" fields.
Start the service (click on Start button on General Tab).
Open a Command Prompt (right click, Run as administrator if needed).
Enter the command:
osql -S localhost\SQLEXPRESS -E
(or change localhost to whatever your PC is called).
At the prompt type the following commands:
CREATE LOGIN my_Login_here WITH PASSWORD = 'my_Password_here'
go
sp_addsrvrolemember 'my_Login_here', 'sysadmin'
go
quit
Stop the "SQL Server (SQLEXPRESS)" service.
Remove the "-m" from the Start parameters field (if still there).
Start the service.
In Management Studio, use the login and password you just created.
This should give it admin permission.