I'm trying to run a database import using the Copy Database Wizard Tool from SQL Server Management Studio in SQL Server 2008.
I have connected to my database using the sa account and when I run the process I used the sa account on both the source and destination database.
All the processes are failing with
Event 18556, Login failed for user '{domain}\administrator'.
Reason: Failed to open the explicitly specified database. [CLIENT: ]
The SA account should have sufficient rights to import the database and the administrator account definitely has the rights.
So, the first question is, why is the administrator account even mentioned since everything is run as SA?
The second question is, why is the administrators account failing to open the explicitly specified database, when that account has total control of all databases on the destination server?
Finally, what exactly is the specified database? There is data in the binary portion of "event log" that points to Master but no mention of the database anywhere else.
Are you connecting to SSMS using pass through authentication? Your wizard will run as your user I believe if so. Connect to your database server in SSMS using the sa account and then try launching it.
Give it a valid account to the other database, sa needs access locally, the 2nd account needs access on your other SQL server.
Alternatively, make sure your domain user has access to the database in question (not the server, the db is dif.) and run it that way.
The master db is where all the sys tables reside, it's the overlord db so to say: http://msdn.microsoft.com/en-us/library/ms187837.aspx
Related
I have an Access DB that I migrated to SQL server recently. The SQL server is on a Windows server. Now I can work normally with the SQL database but when others log into the same windows server with their credentials they are not able to access the database. As soon as they open Access frontend they get an error saying failed connection. Now I created an ODBC connection string(File DNS) and gave it to the other users in the network but they still are not able to connect to the database. They get an error stating "SQL server connection failed. The server rejected the connection: Access to the selected database has been denied". Can someone please help me to solve this issue so that multiple users can connect to the SQL DB without any issues? Thanks
Hard to know with the limited information. Are you using windows authentication to sql server, or are you using SQL logons? Either should work fine. The other issue to watch out for is what sql driver did you use to link with?
If you link say using the native 17 ODBC driver, then that is not installed on workstations by default - you have to download and install that driver.
Or, maybe you linked using the long time "legacy" sql driver - that is by default installed on all workstations.
So, it not clear if you using SQL logons, or using Windows authentication for the connection to the database????
If your using windows authentication, then all those other users will require permissions to be granted to the database.
If you using a SQL logon, then that logon would have been saved when you link the table(s), and again it should work for all users. Its quite common to create ONE logon on SQL server, link using that logon, and thus all users will be connecting to the database using the one same logon id/password.
And, if you linked using a FILE dsn, then zero configeration should be required, since access converts FILE dsn's into what are called dsn-less connections. (the origonal file is not required anymore once you link - you can even delete that FILE dsn, and it will still work).
So, FILE dsn is the best choice, since that dsn is NOT required to be setup on each workstation.
And if you using sql logon's, then make sure you checked the box to remember the password during linking of the tables. That is this check box:
And note during a re-link the above box does not appear - only on first time linking of table(s).
Contained and login user passwords from the source aren't working in the target after restoring a .bacpac from one Azure SQL Server onto another Azure SQL Server.
The users do exist in the target SQL Server database, but they are unable to login with the same password from the source in the target SQL Server.
How can we keep intact and make the passwords work?
I too faced this issue a year ago and after consulting Microsoft support, they confirmed that this is by design that the passwords are changed in the background for security reasons. I would suggest you to run a script or procedure to alter user passwords back to original ones after restoring the database from bacpac file.
ALTER USER [USERNAME] WITH PASSWORD=[PASSWORD]
Apart from the solution to alter user passwords, you can see the resolution strategy given by Microsoft support -
I have a database I've created on my local machine that I can't seem to correctly deploy to SQL Azure. I'm deploying two databases, including the one that provides user membership.
Every time I attempt this, when I try to login and access to the database is attempted, I receive a The system cannot find the file specified error:
I've tried deploying the database every way I could from Microsoft SQL Management Studio - by right clicking my databases and "Deploy Database to SQL Azure", by generating drop and create data only SQL scripts and running these against an existing target database, by creating a bacpac and importing this and all of these have the same result.
I've double checked connection strings in my .NET MVC applications web.config and these are all correct.
Interestingly, if I run my website locally with connection strings that pointed to my updated Azure SQL db, everything works fine - but on my Azure Website I always get the same results.
Your issue actually looks like a connection string issue but if anyone else ends up here thanks to Google you can resolve orphaned users on Azure SQL Db using:
ALTER USER <user_name> WITH Login = <login_name>;
I am not a AZURE expert, but when moving DB's from one server to another sometimes user's get orphaned making the DB not accessible.
Can you run this command on the AZURE DB via SQL MANAGEMENT STUDIO?
exec sp_change_users_login 'Report'
It will tell you what username and UserSSID may be orphaned. If indeed there is a returned record run
EXEC sp_change_users_login 'Auto_Fix', '[[UserName_goes_here]]'
I am trying to backup my sql server 2005 database using the query
backup database marksheet to disk='e:\backup\marksheet.bak'
when i execute the query it shows the following error
cannot open backup device 'e:\backup\marksheet.bak' operating system
error 5(access is denied)
I am using windows xp
please help me..
The account running the SQL Server service does not have access to that folder.
It doesn't matter if you have access to that folder.
You need to check the security permissions on the folder you are trying to backup to. Make sure the service account (Network Service) has write permissions. It may well not do.
SQL on changing the service account changes the permissions on the critical drives it knows about but won't do it for all the drives in a server.
Try adding the domain account that runs all SQL Services to the security of "e:\backup\".
I am a developer-having-to-play-admin and wish to connect to a remote sql server from my development machine using a sql server user ("op_web").
When I try to connect from vs2008 Server Explorer, I can connect to the server, but no databases are listed. If I connect using the server admin user, all databases are listed as expected.
The server is a relatively fresh install made by me.
I have
allowed for remote connections in sql server.
created the login op_web at server level
created a user at database level and assigned to login with same name
assigned roles to the user to allow for reading and writing - I have assigned no schemas and default schema for the user is dbo.
If I log on (locally at server) using sqlserver management studio/sqlserver authentication and the created login, I can display and alter table data as I would expect.
Remote access gives me no choice of databases.
Any pointers to what I might have missed?
You have to give your users rights on the database.