I am using Access to try to get some links to tables in SQL Server 2008.
I've created a user name under security in SSMS for SQL Server and I've mapped it to a user that is under the database that I need. I've also given that user a default database that I need.
When I try to connect through ODBC I am not seeing the correct tables. What I am seeing is a bunch of Sys tables. Does anyone know what I am doing wrong?
Here is the create for the main user:
/* For security reasons the login is created disabled and with a random password. */
/****** Object: Login [lomuser] Script Date: 10/22/2010 08:14:03 ******/
CREATE LOGIN [lomuser] WITH PASSWORD=N'µ''ØÑëOº\¾dõMÐàæfÄ%[RríÜ2 y', DEFAULT_DATABASE=[LOMDATABASE], DEFAULT_LANGUAGE=[us_english], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
ALTER LOGIN [lomuser] DISABLE
GO
Here is the create for the specific user to the specific database (on which the top user is mapped to) also FYI they have the same name:
USE [LOMDATABASE]
GO
CREATE USER [lomuser] FOR LOGIN [lomuser] WITH DEFAULT_SCHEMA=[dbo]
GO
When you setup the DSN connection in the odbc panel or let access create this connection for you, the default database is master. So, when you link a table, the only tables you will see are the system tables. Delete your linked table (if you have any). Now, when you choose to link to a table, choose NEW in the data source to create a new DSN connection. During that process, you see the option to change the default database from system to whatever database you want.
Once you change the above default, then when you link a table, you see tables from the above selected database you choose. If you did not set above, as noted, you just going to see the system tables.
You may find a solution in this article at Microsoft support
This is a known bug in SQL Server
Beware of denying Select to the Public
because it has unintended results elsewhere
The solutions can be difficult for a casual SQL administrator.
By default when setting up (importing) a linked table from an (Azure) SQL Server database MS ACCESS chooses master as the default database. You should change this when linking the table:
1-Click Linked Table Manager under External Data tab
2-Click Add button on the right menu bar and choose SQL (Server/Azure), enter a name for the data source (so you can recognize the data source later in the Link Table Manager list of sources), click Next
3-When SQL Server Login wizard prompted, enter the address of your SQL server e.g. for Azure it should be something like this:
<you_server_name>.database.windows.net
Enter your SQL database user and password for login.
Once done, the button Options will be enabled
4-Click button Options and you will see the Database is set to Default. Click on it and choose the database you want. You should see the tables of the selected database and not master
Related
I am having some trouble creating a new SQL user in SQL Server 2008 R2. When I use SQL Server Management Studio it checks db_owner role membership by default. I just want to create a new sql user with read only access. Even with the following raw SQL it still creates the user with db_owner level permission.
<!-- language: lang-sql -->
CREATE LOGIN readonlyuser
WITH PASSWORD = '12345',CHECK_POLICY = OFF, DEFAULT_DATABASE=mydatabase
GO
USE mydatabase
GO
CREATE USER readonlyuser FOR LOGIN readonlyuser
GO
EXEC sp_addrolemember 'db_datareader', 'readonlyuser'
Now if I log on to SQL Server Management Studio with newly created user I can basically access any table and modify any data any way that I want. This is exactly what I not want to do. I want only to be read data and not to modify any data
Strange thing is if I look at the roles for database the readonlyuser is inside db_datareader and not in db_owner.
So why is SQL creating this user with db_owner level permissions, thus allowing the user to modify data?
Update 2013/08/07
This seems to be happening with just one specific database. I created brand new database and created bunch of tables and then ran the same script above and it is working perfectly fine. But if i try with the actual database where i need this change, it doesn't work like that. It created the user and gave way too much permission.
Is there anything that i can check on that database? Please note that specific database was not designed by me. It is from a 3rd party vendor. So not sure exactly what modifications they might have done.
Any help is greatly appreciated.
I ran into the same issue.
The solution: sp_changedbowner. That fixed it. (Somehow the owner was corrupted)
I don't see any problem in query. And it worked as expected when i tested it. Just for confirmation, verify if user is properly mapped to required database (mydatabase) and db_datareader is selected from user property window.
I found that this happens to me when adding logins to databases that I restored to a new server. In the Files tab of the database's properties, the owner field is blank, even though it lists a user in the General tab. If I populate the owner field with a valid login, then the problem is resolved: new logins don't have "db_owner" checked by default.
To expand on Greg's comment, this probably happens when the restored database was owned on the source server by a login that's not present on the current (the destination) server. The info on the General tab is the original owner (on the source server), which cannot be reflected on the Files tab, since that logion is missing on the current server. In a certain sense this is an "orphaned database" then.
I have been asked to maintain a site created in ASP classic that uses a SQL Server database.
I was given the database in the form of a backup. I restored the database on my local computer and created a DSN connection to it. However when I attempt to load my site, the stored procedures the site relies on give an error that execute permission was denied.
The stored procedures in question have a user named UserSecure showing as the only person with EXECUTE permission, I have tried creating a user by that name but that does not work, even though I can manually login to SQL Server Management Studio using UserSecure trying to connect from the web page using those credentials gives a login failed error.
If I run sp_helplogins my Windows credentials are shown as being owner of the database, and I can in fact execute from within SSMS but not from an ADO connection.
On another note the connection in the webpage was coded like this, I am not familiar with the application part of the connection. Perhaps this is part of the problem? I have tried connecting with a DSN and DSN-less connection and can connect but not do anything with the database?
You should make sure the database server login is mapped to the appropriate database user (this problem crops up often when dealing with database backups). If it is not, then you need to fix the mapping. Fortunately, there is a command called sp_change_users_login that you can use to fix this problem.
First, check if your login is mapped to your database user. Using SQL Server Management Studio (assuming SQL Server 2008), look under Security/Logins for UserSecure. If you see it in the list, double click on it and select User Mapping. From there, locate the database you are trying to connect to, and see if UserSecure is mapped to that database. If it is not, you may be able to fix it using the following command (assuming UserSecure is the name of both the login and the user):
EXEC sp_change_users_login AUTO_FIX, UserSecure
See MSDN for more info on sp_change_users_login:
http://msdn.microsoft.com/en-us/library/ms174378.aspx
One issue that has bitten me a few times:
If your stored procedure (or view) requires permission from a user (let's say userA), and the stored procedure calls another database's table or view (say viewB), it is not sufficient to just make a login on viewB's database, you must also explicitly grant userA permission to select/execute/etc. on viewB (which in turn requires a user on viewB's database)
So in your case, you may need to explicitly grant UserSecure execute permission on a stored procedure on an existing database referenced by the one you restored.
This may not be the most elegent fix, but I quit focusing on the one procedure and instead granted execute permission to the guest user on the entire DB. Since this is only running on my personal machine security is not an issue and it seems to have fixed the problem.
Know the problem all too well,
The ID of the user(name) will be different from the backed up database to the restored one. MSSQL stores the ID of the user and not the username (text), so the ID will be different (99% of the time) per machine and backup. So when the ID does not match you don't have access.
All you need to do is delete the user and recreate it, make sure you do it in both places:
Delete the user from the database first:
DATABASE -> SECURITY -> USERS -> Right click (username) + delete
Then goto
SECURITY -> LOGINS -> Right click (username) + delete
Then recreate the user and give the account the correct permissions and you're all good.
I would like to change the default database for a login to support software that can access SQL Azure but does not allow easy alteration of a connection string. It appears that SQL Azure defaults to the master database.
I've already considered:
Stored procedures. I can't find a stored procedure that does this (sp_defaultdb is not implemented in SQL Azure as far as I can tell)
Alter Login. ALTER LOGIN does not permit the DEFAULT_DATABASE option.
SSMS. SSMS doesn't seem to allow much user control through the interface for SQL Azure.
Ideas?
Connection String:
Server=tcp:[serverName].database.windows.net;Database=myDataBase;User ID=[LoginForDb]#[serverName];Password=myPassword;Trusted_Connection=False;Encrypt=True;
You can change connect default database, when you write 'Database' property at connection string.
SSMS is connect to database box which is option->secont tab at conecct dialog.
In my case I managed to do it by creating a login directly in the master database:
CREATE LOGIN newlogin WITH password='password'
GO
CREATE USER newlogin FOR LOGIN newlogin WITH DEFAULT_SCHEMA=[dbo]
GO
Then I created a user in the database I wanted to gain access to:
CREATE USER newlogin FOR LOGIN newlogin WITH DEFAULT_SCHEMA=[dbo]
GO
At last adding it to a role in the particular database to gain the right permissions:
Alter role db_owner add member newlogin
Hope this works for you too.
As you already discovered the DEFAULT_DATABASE option is not available in SQL Azure. So if you cannot change the connection string of your application in which you would normally specify the database name, you are stuck to master.
However... is it possible to create an ODBC connection, and configure your application to use ODBC? Using ODBC would allow you to specify a default database.
By far the easiest way in SSMS is to use the additional parameters tab and supply the initial catalog, e.g.
You can easily change the default database when loging in with SSMS. Click the Options button on the Login Dialog then click on the Connection Properties tab. In the "Connect to database" box enter the name of your database.
You have to use use following to be able to change "default" Database
Use "SQL Server Native Client 10.0" or higher instead on using "SQL Server as Driver
Use full user id like UserName#AzureConnnectString
For me it is
NorthWind#w6ywertsd8h.database.windows.net
More details here
http://debugmode.net/2011/04/22/connecting-microsoft-access-to-sql-azure/
Another option is to create a mapped user in the master database and the hosted database. This will allow SSMS to connect to the server and use master as the default db, then the user can open the database. I am not a DBA so I do not know the implications of this, but that is how I solved it. My database is just being used for a POC project so it doesn't have many security requirements.
I am attempting to migrate from SQL Server 2005 to SQL Server 2008. Both of these database instances are hosted on 3rd party shared servers that I do not have full permissions to. They are using mixed mode authentication.
I am running into trouble setting up the new database the same way the old one was set up. Specifically, the new web-based control panel doesn't allow a dbo to be specified when creating a new database and then when using Red Gate SQL Compare to sync up the schemas I am having problems because some objects (that don't explicitly specify dbo in the script) are being created with the prefix of the user account rather dbo.
I have poured over the documentation trying to find a way to force my login "user1" as dbo to the "db1" database. I came to the conclusion that the script should look like this:
ALTER AUTHORIZATION ON DATABASE::db1 TO user1
Before running this script, the login "user1" already exists, but is not a user for database "db1". Note I had to submit this script to the support of my hosting company in order to run it. According to the hosting company the statement successfully executes, however when I compare the databases using SQL Compare the user "user1" has not been physically added to the database like it was under SQL Server 2005. When trying to add it using the script:
CREATE USER [user1] FOR LOGIN [user1] WITH DEFAULT_SCHEMA=[dbo]
I get the error message:
"The login already has an account under a different username"
I have tried dropping all of the other users from the database, but the error message still persists - which I find odd.
While I could just fix the scripts by explicitly specifying dbo, this would inevitably be a time bomb waiting to go off because if any new script were introduced that didn't explicitly specify dbo there would be a failure during synchronization. Since some of the scripts are from 3rd parties, this is not a good solution.
So my questions: Is there another statement that I need to run in order to add "user1" to the database as a user that is dbo? Is there anything that has changed in the implementation between SQL Server 2005 and SQL Server 2008 R2 that could cause these inconsistencies?
I am unfortunately not able to test to find an answer to the second one because I don't have another SQL Server 2008 database to test with and I don't have full access to do anything I want on this one.
The old database was created through a control panel which forced dbo to be specified and the new one doesn't allow dbo to be specified when creating a database.
From what i have gathered the following should suffice.
ALTER USER [user1] WITH DEFAULT_SCHEMA=[dbo]
The create wasnt working as it already existed.
I have taken a copy of a database home with me so I can do some testing. However when I try to run a stored procedure I get Cannot open user default database. Login failed..
I have checked and checked and checked I can open tables in the databases login to sql management studio and access the default as well as other databases any ideas?
Possibly a corrupt user it was from sql 2000 at work to 2005 at home
EDIT: Mine was from 2005 to 2005. Not sure if this will work for your case...
I had a similar problem. For me, when I detach or create a back up and then re-create the database, it will loose connection to users. User I've been using is still there under Login but it would fail to log in.
In my case, I was able to log in by deleting the User under the database -> security -> users, not the user that's in the root sql server users list.
Then go to root users list and reassign database mapping or create user if not exists.
Hope this helps.
This is a shot in the dark, so forgive me if it just wastes your time.
Another poster mentioned that a given user has an id for the system and an id for any given database. This can be proven out by comparing sid's between the master.sys.syslogins and dbname.sys.users for the same login / user name. If you restore a backup from another sql server that has it's own copy of the master databases, the sids won't match.
Sql Server 2005 doesn't allow direct editing of system tables with out a lot of pain. To help out with these mis matches, they added a stored procedure to help you fix them:
USE dbName
GO
sp_change_users_login #Action='Report'
That will show you what users have a dbName.sys.users entry, but no master.sys.syslogins one - or where the name exists in both, but differ by sids.
If it shows that your user is out of synch, the procedure also has a mode to change the linking:
USE dbName
GO
sp_change_users_login 'Update_One', 'userNameInDbUsers', 'UserNameInLogins'
If the sid mis-match isn't your problem, I've also seen really screwy stuff with Sql Server 2005. The gui is especially buggy. To fix a problem like this, I had to actually drop the syslogins entry (via the gui or DROP LOGIN command )
sp_change_users_login: http://msdn.microsoft.com/en-us/library/ms174378(SQL.90).aspx
Drop Login syntax: http://msdn.microsoft.com/en-us/library/ms188012(SQL.90).aspx
I had the same issue and I fixed it with:
C:\> sqlcmd -E -d master
1> ALTER LOGIN ***** WITH DEFAULT_DATABASE=master
2> GO
Where ***** is your username.
(If you are using a domain username: [*****])
Edit:
Where ***** could be:
username if the user is local
[username] if the user belongs to the actual domain
[domain\username] if the user belongs to another domain (not tested)
I moved 8 databases from SQL Server 2000 to SQL Server 2005 and onto a whole different computer. I normally like to know what stored procs are doing so I dug a little bit and found that the actual command is ALTER USER.
It's what everybody else has been saying. The users get disassociated when you detach and reattach databases in SQL Server 2005. I find this behavior most annoying, as I didn't see that behavior in SQL Server 2000.
The T-SQL to fix this issue looks like this:
USE AdventureWorks;
ALTER USER Mary5 WITH NAME = Mary51;
GO
This MSDN article talks a bit more about this:
http://msdn.microsoft.com/en-us/library/ms176060.aspx
I just solved this issue. My default database was AdventureWorks2008, so as an Administrator, I ended up removing my login from the server. Then running the following to recreate my user
CREATE LOGIN [NT\mylogin] FROM WINDOWS WITH DEFAULT_DATABASE=[Master], DEFAULT_LANGUAGE=[us_english]
GO
My understanding is that Logins are stored in the server, whereas a User is an assignment of a login to a database (correct me if I'm wrong).
Therefore, you cannot move Logins by detaching/attaching databases, and the solution would be to create a database User connecting a (valid) login to the copied database.
http://benharrell.wordpress.com/2007/01/15/cannot-open-user-default-database-login-failed-login-failed-for-user-username-microsoft-sql-server-error-4064/
ALTER LOGIN works only in SQL 2005 and up.
To change the default database for a user in 2000 use
EXEC master.dbo.sp_defaultdb #loginname = N'BuiltIn\Administrators', #defdb = N'master'
I found this out the hard way when I set the builtin\administrators account to default to the application db and it went Offline somehow and I could no longer login. Using Management Studio, you can set the option to login to master but you must run the above command before any other operation will work, less you get the default database is unavailable error.
As was mentioned before, the login mapping to that user account probably became disassociated during the move. Or, you moved it without creating the credentials it was expecting, in which case, you'd need to create the login first...
If it was a backup set and you are restoring it, however, there is no way (that I know of) to reassociate the login to the user via the management UI. Instead, you have to use:
exec sp_change_users_login update_one, 'user', 'login'
to get it to restore the link.