Is it possible to import an MS Access. mdb file into SQLExpress if I do not have MS Access installed? Reason I ask is because I am getting the following error when attempting to use the Import Wizard in SQL Management Studio to perform this task:
"Test connection failed because of an error initializing provider. Cannot start your application. The workgroup information file is missing or opened exclusively by another user."
If the .mdb file is encrypted with user-level security then you need to provide the SQL Server import wizard with
the username and password to connect to the database, and
the location of the Workgroup Information file (.mdw)
In the SQL Server import wizard, click the "Advanced" button...
... and then on the "Connection" tab
un-check "Blank password"
check "Allow saving password"
enter the "User name" and "Password"
On the "All" tab, select the "Jet OLEDB:System database" property and click the "Edit Value..." button...
...then enter the full path to the associated .mdw file
After saving the changes you should be able to proceed with the import to SQL Server as usual.
I just removed the database password and that worked for me.
Related
When you want to login different servers using "Object Explorer" tool, SQL Server Management Studio 18 overrides passwords with same username.
For example, login a server with "remember password" option like following
Server: ASERVER
Login: auser
Password: apassword
And then login to another server (again "remember password") like following (same user name different password)
Server: ANOTHERSERVER
Login: auser
Password: anotherpassword
Unfortunately SSMS overrides the first username/password. That is, if you try to reconnect ASERVER again SSMS gives username/password error. This is so annoying. Any help?
EDIT: The problem is actually very simple. Open a connection SERVER1 and then SERVER2 using the Object Explorer. If user name has same, SERVER1 password is gone.
EDIT 2: SSMS's password management switched to Windows Credential Manager with version 18: https://learn.microsoft.com/en-us/sql/ssms/release-notes-ssms?view=sql-server-ver15#download-ssms-180
Unless you remove that server from the SSMS Server History, it'll still not save the fully qualified settings in Windows Credentials. It'll save an entry with the UserName/Password instead of the ServerName/UserName/Password.
TL;DR
Open Registered Servers (Ctrl+Alt+G) and delete all the severs in the Local Server Groups (not sure if critical but I did).
Open the File menu, Connect to Server selection. In the dialog,
dropdown the Server name and use the arrow keys to highlight the
affected server name and hit the Delete key to remove it from the
SSMS history. This step is critical.
Now that the entry is out of the SSMS History, use that same dialog to connect to the server making sure to click [X] Remember password.
Voila! If you look in Windows Credentials you'll see the entry with the fully qualified ServerName:UserName.
More Detail...
The Windows Credentials are visible at:
Control Panel\All Control Panel Items\Credential Manager
If you have connections saved in the 'Local Server Groups' under "Registered Servers", they won't be migrated automatically to Windows Credentials correctly.
It will create a Windows Credential record for that connection's username but without the server names scope. This seems to be the real problem.
Here's the Windows Credential for my common logon. Note the missing ServerName between the two colons:
Microsoft:SSMS:18::MySampleUserName
It should've been:
Microsoft:SSMS:18:MyServerName.Domain.com:MySampleUserName
If you have the same username for 2 or more servers, this one Windows Credential record password will be overwritten each time you logon.
I tried deleting this entry from the Windows Credentials but that wasn't sufficient to fix the problem for me.
It is not 100% clear when the problem occurs. According to my tests, if you have 2 different connections to same server in object explorer and you create new query window from object explorer, the connections are applied correctly.
Maybe you are talking about recent connection in the "New Query" command?
If you have to deal with multiple connections you can use at least built-in "Registered Servers" functionality.
Or, you can use SSMSBoost add-in (that I develop) to have seamless "preferred connections" and "recent connections" management.
Here is a video about the feature: https://www.youtube.com/watch?v=5Up6EQux9LM
Description: https://www.ssmsboost.com/Features/ssms-add-in-preferred-connections
I am trying to import an Excel file into SQL Server 2016 using a SQL Server Management Studio remote client. When I run the SQL Server Import and Export Wizard, I can successfully define the Excel file as the source but I get a "login failed" error when defining the destination.
Here are the Destination parameters I'm using:
Destination: SQL Server Native Client 11.0
Server name: MyServerAddress, Port
Authentication: Use SQL Server authentication
Username: MyDatabaseUsername
The error I get when I click "Next" in the Wizard is:
login failed for user 'MyDatabaseUsername'. (SQL Server Native Client 11.0)
I'm sure I'm providing a valid username and password for my destination database.
Any idea why I'm getting a "login failed" error?
Figured it out ... The SSMS Import and Export Wizard dialog box was sized in a way that hid the password field (plus a couple of other fields). I had no idea that the dialog box needed to be resized, except I just by chance pulled on one of the edges of the dialog to resize it and wham-o ... the extra fields appeared out of nowhere.
Thanks to robbpriestley for giving me a clue and making me think!
I have an accdb access database (2007-2016 version), I am trying to set up a SSIS package to import data to SQL Server via the SQL Import wizard. It all works fine if the access database doesn't have a password but when encrypting the accdb file it doesn't work. I have tried to set the password in the import process but it doesn't recognise it. Any help?
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.
When I try to connect to SQL Server 2005 Enterprise edition on my local machine I get the below error:
"Cannot open user dafault database.Login failed.
Login Failed for user "Domain\My name"
What can cause this error?
From SQl Server management studio try this
click the options button .
click the connection properties.
click on the Connect to database
type in the name of a database "master"
click connect.
Bye
Either the login's default database no longer exists, or the login has no rights to it. What version of SQL Server?
Another reason can be because SQL Server is failing to contact the domain controller.
If it can contact the domain controller then Kerberos could be failing due to a skewed system clock or active directory not containing service principle names for the server.
You can check for Kerberos authentication errors in the system's event log.