I retrieve data from SQL Server database to excel file.
When I define connection properties, I choose that I want store password.
Meanwhile, I create a new login (and grant only access to read only data from specified database).
Unfortunately I am unable to find any option in Excel to remove this stored password.
In files which defining connections (.odc extension), I found information about login, but nothing about password.
How i can do it?
Maybe obvious, but did you try to unckeck the Save password checkbox in the connection properties window and reconnect to the database?
See http://office.microsoft.com/en-us/excel-help/connect-to-import-sql-server-data-HA010217956.aspx
Related
Our business has just changed Active Directories and the domain changed, from "YMS" to "YMSNET". So I used to be able to log in with "YMS\tkol" and I can now log in with "YMSNET\tkol" (these usernames and domains are faked for the purpose of example), but when I log in as that now, I can't actually expand any of the databases or look at any of the tables, I can just see a list of the database names. When I try to expand a database in the UI it says "This database is not accessible (Object Explorer)."
Now I have another user, called "sqluser", and I keep trying to use that user to log in as well by changing the Authentication Method to SQL Server Authentication rather than Windows Authentication. But I get Microsoft SQL Server, Error: 4064
Now I know this sqluser user exists and the password is correct, because I can authenticate to the server and successfully interact with the tables from an external process on a separate computer on the same network (node.js, package mssql). And I used the query on the accepted answer on this question, and found my sqluser is there, with roles db_accessadmin, db_ddladmin, db_owner. And yet it still won't let me log in with that user in the SQL Server Management Studio UI
How can I get this working again and log in with my sqluser account? Or add the appropriate permissions for my YMSNET\tkol account?
--- edit ---
My first idea is that, because I can log into the UI with YMSNET\tkol, but I can interact with the databases externally with sqluser, that there is some query or command I can run with sqluser that will add permissions for YMSNET\tkol so that that user can now look at all the databases and tables. I don't know which commands I'd run for that.
It can be because your account's default database is mapped to some another db which is not available for you, for instance, you have no permissions there, or that database not exists anymore etc.
Your organization DBA can fix it by:
ALTER LOGIN [sqluser] WITH DEFAULT_DATABASE = [rightDB]
Default db name can be checked by:
select default_database_name from sys.server_principals
where name = 'sqluser'
This property can be overridden by opening "Options" of SSMS connection window and specifying it explicitly:
I have some reports and a data source on a share point. Everything is working correctly, but I need to change the account used on the data source. I gave permissions to this new account to login in SQL server. When I set the credentials of the new account, on the share point data source, it fails with this error "Log on failed. Ensure the user name and password are correct.", but if I log in using the new account directly in SQL Server it works correctly. I think the problem is only when I try to log in using the share point data source.
Regards and thanks!
Check if the new account have the permission for SharePoint, if not, add the new user to SharePoint and set permissions for this user.
And I suggest you provide more information about the data source.
I'm working on an application right now that requires a link to a couple of SQL Server tables. My windows network account has permission to connect to this server, but I am not going to be the only one using this application. I'm going to send it out for people to save to their PC or just put it on the company shared drive to use (I know, that's asking for problems sometimes). It's inconvenient to make a windows account for users to share because they would need to log out and in to use the app, so I was wondering if the application or ODBC connection file itself can store the credentials to access the table.
Should I configure the connection object to use something other than the windows login information (maybe a SQL server username/password), and just store the connection object in a shared location? I don't have much experience with this and haven't tried out many different solutions and I am open to suggestions.
Thank you for the suggestions
As suggested in a comment to the question, one solution would be to
create a User Group in Windows on the SQL Server,
create a SQL Server login for that group,
assign permissions within SQL Server to that login,
and then just add or remove particular Windows Users from that group as required.
That way you don't need to mess with the various SQL Server permissions for each database user, and your application can connect to the SQL Server using Windows Authentication so you don't have to mess with saved SQL Server credentials (in connection strings, or elsewhere).
You certainly can specify the username & password in the connection string -- ConnectionStrings.Com is highly recommended if you are having trouble with connection strings -- their first example for Sql Server is
Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;
The issue is security, if users can see this in a configuration file, they can do anything that account can do. You have to handle security within you application if you do this. Most apps that handle their own security have to create users and passwords in a database table (best not to store password at all, much less plaintext -- a one way hash is recommended).
One good strategy is the create a "login user" account with well known name and password, grant no read / write, etc. for that account at all, and grant execute access to single stored proc
IsLoginPermitted #ID, #PASS
When successful, IsLoginPermitted returns the ID & PASS for subsequent use (of course these are hidden from the user) and you create your new connection string based on these.
So I created a new database on my SQL Server box and then added an ODBC entry so my ASP code knows what it is. Now I am getting this error:
Cannot open database "DB_NAME" requested by the login. The login failed.
I checked out the permissions by right clicking the db in Management Studio and checked permissions and low and behold it is empty.
I am just trying to duplicate the permissions of one of any of the other twenty or so databases sitting on the box. Is there a quick way to do this? Either way I just need to open up the lines of communication between my ASP code and my SQL Server db
Here is my connect code in ASP:
Set sqlConnection = Server.CreateObject("ADODB.CONNECTION")
sqlConnection.Open "DB_NAME"
Is there some reason to avoid using a proper connection string:-
sqlConnection.Open "Provider=sqloledb;Data Source=myServerAddress;Initial Catalog=DB_NAME;User Id=myUsername;Password=myPassword;"
On top of what John said, when you create a new database, you have to map the login (either SQL login or Windows login from Application Pool) to this database. You can use management studio to do this - open login properties and map it to the new database. Open Object Explorer, then click Security, Logins and rightclick login that is used by your application. Select Properties. Click User Mapping and add appropriate entry for your database in the grid you will see.
The other option is to run statement to create user within the database:
Use DB_NAME
go
create user [web_user] from login [web_login]
go
Another question is to see what rights have to be assigned to the user in the database. You have to check users permissions in one of the existing databases. Again in Object Explorer, click your existing database, then Security, Users and rightclick Properties of the user that you want to check. Observe information displayed on the dialog box in the General tab and check if there are any Securables assigned to the user. You have to copy these settings to the user in your new database.
HTH
Piotr
Try adding the user id and password into your connection string.
I prefer to keep our SSIS packages in a solution on the server, not in sql. By default, sensitive data is encrypted with a user key. Since the sql server agent uses a service account to run jobs, we have to change this encryption method to something else. I like encrypting with a password.
The problem is whenever I setup a job in a step there is no place to input this password. When I click on the configurations tab, I get a popup dialog for the password. That keeps it stored properly, but is this really the right place to put it. It seems really unusual, and I keep running into issues where it seems to reset itself if I make certain changes.
Does anyone know of a better place to input this password that is more stable?
Thanks,
There is no need for you to have a password in the package at all if you can use Windows authentication and avoid SQL Server authentication and ensure that the rights necessary to execute your package are available to your service account.
Barring that, you should already be overriding the connection string with a config file using package configurations so your package is portable, and then the password doesn't need to be in the dtsx anyway.
The way you deploy your package and store your package in your local project solution can be different. You can save sensitive data with a password when saving your packages locally and "rely on server storage and roles for access control" when deploying the package. Although the data will not be stored in an encrypted format in the msdb database, you can restrict access to the password information by managing pre-existing database roles.
You need set the password on your Job.
Go to the properties of your Job > two clicks over your Step > in the tab "General" type your login and password, than in the tab "Configuration" type your password (the password that you put inside the SSIS)