SQL Server login error over ODBC connection - sql

I'm working on a project using SQL Server 2012 and I am running into an issue while attempting to update a login.
I was attempting to add DDL permissions to a login and when I went to hit OK and close the properties window, I received this error.
I closed the login properties window and reopened it to find that the login's database role changes had indeed been updated to reflect the changes I made.
It looked to me like my changes had been committed, and then this error popped up.
I went to connect over an ODBC connection I had made earlier for the same login, but discovered I no longer could, I was getting this error from the ODBC.
I know for a fact that this ODBC connection was working for this login at some point before my changes since I had a linked table that was using this same connection. It was able to both pull down updates from the SQL Server and push through changes back up to the server level.
Can anyone help shed some light onto what a solution to these errors may be? I assumed they were related since they both began occurring this morning, but I'm not positive of that fact. My database administrator is out of the office till tomorrow, so I'd really like to get this resolved before then.
This is what I get when I try to use that logon through SSMS

I'm putting this into an answer, since it solved OP's problem. I don't know what happened during/after the initial error (when granting DDL permission), nor exactly what the other errors were pointing to.
Because the user was unable to login through ODBC or SSMS, the first step would be to check the user and login properties in SSMS, to ensure that, for example, it is enabled, and that it was granted permission to the database.
In the comments, OP found that the user was not setup with GRANT.

Related

How to delete a corrupt database from azure sql

I have tried to delete a SQL database from the azure portal. It looks like it has failed part way though. The database doesn't show up under the list of SQL servers in the Azure portal. However if I login to the server through SSMS it is still there. I now can't delete the database or create a new one with that name.
I've tried deleting the database with a query and get an error saying the database doesn't exits. If I try to create it either from the Azure portal or SSMS it gets an error saying it already exists.
I had a similar problem once, with SSL settings, where it would return that it is linked to the app even tho it wasn't, hence I was not able to delete it. After a couple of weeks of back and forward with the support, we removed it through azure resource explorer.
How to:
Once you are logged in, set read/write
In serach box find your resource
Click actions (POST/DELETE) // these should be available now since you have set read/write
Click Delete
Hopefully, this would help anyone who has any corrupted resources in Azure.

SQL Server Security Permissions issue

I have a strange issue when trying login to my WPF application I published. I am using Microsoft SQL Server 2016, I am also a Server admin. I have a Database called Project Tracking in the server. When trying to log in I am able to login just fine. When another user tries to login they get this error: The underlying provider could not be opened.
Now, if I add them as system admins to the SQL server they are able to login just fine no errors. Although this is not what I want to do for obvious security reasons. How do I go about actually adding them for read/write access to the database?
The connection string in the application is: "metadata=res:///Model.ProjectTracking.csdl|res:///Model.ProjectTracking.ssdl|res://*/Model.ProjectTracking.msl;provider=System.Data.SqlClient;provider connection string="data source=EPLANDB\PROD4W;initial catalog=ProjectTrackingDB;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework"" providerName="System.Data.EntityClient"
This is my first go around using SSMS and SQL Servers, so not sure what exactly the problem is or how to word it correctly, I hope I gave enough information if someone could point me the right direction.
Here is a picture of my setup on SSMS.
I figured it out. I found this article over the subject and it worked for me.
I had to go into Security for the Server right click Logins and hit New -> Login.
Your are then brought to this screen. Click Search...
Not sure if this part matters. But I clicked Object Types and checked the Groups.
Add the username you want to include. Make sure to include the domain name.
Click User Mapping.
Check Your Database.
Make sure to check data reader and data writer and any other roles you would like to include.
Here is where I found the solution.
Answer to Problem

Login Failed for user?

I am developing a web app that connects to a SQL 2000 database. Everything works perfectly on my database (which is actually SQL 2008) but when I try to migrate it onto another server (that's actually running SQL 2000) I get some strange errors.
I'm getting Login Failed for the username that the web app uses, so I did my normal troubleshooting steps...
I reset the password to what it should be, made sure the user was mapped to the database it's trying to connect to. I connected to the database through Enterprise manager using the user name and password and was able to run queries. I reset the SQL server.
I'm fresh out of ideas other than there might be a place in my app that the password is for some reason getting changed. Is there anyway to see what password the SQL server is seeing? I just want to narrow down my search a little.
Either that or does anyone have any other suggestions on how I might be able to fix this?
EDIT: Also, the web app CAN talk to the database, it hits the database to get login credentials and it can login with no problems. The error is coming up later in the app when I try to get more information from the database, like parameters for a report or an export location.
Thanks in advance!
First, the problem is not that the login failed for a user. From your description, the login succeeded. However, you stated that you later got an exception when trying to access certain objects. This sounds like an authorization/permissions issue with the database user to which the login is associated and the objects it's trying to access. Have you tried connecting to the database using Enterprise Manager and the same credentials used by the site and executing the identical query as the web application?
Possibly your SQL server isn't set to allow remote connections?
EDIT: or your firewall doesnt have the right ports opened?
EDIT2:
If your web script is on the same server as the SQL server, the only thing that i can think of is that you have specified an incorrect password, of if you referenced the old server by name (even though it was localhost) and you have not updated it. If the web script is on a different server, check your firewall ports and ensure the sql server is set to allow remote connectioins.
EDIT3:
Appologies, i didn't see your update before i posted the last edit (EDIT2). Thomas is right, give that a go.
Not sure how you're doing your migration but you may want to make sure your sql user is not getting orphaned:
From - http://www.fileformat.info/tip/microsoft/sql_orphan_user.htm
First, make sure that this is the problem. This will lists the orphaned users:
EXEC sp_change_users_login 'Report'
If you already have a login id and password for this user, fix it by doing:
EXEC sp_change_users_login 'Auto_Fix', 'user'
If you want to create a new login id and password for this user, fix it by doing:
EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password'
I found the problem!
It was actually some lingering queries I had in the app. I started populating some down downs differently and the queries were never removed, as soon as I took those out the errors stopped popping up.
Still it's strange that this would not effect the app on my machine but on this other machine would cause all kinds of havok.
Thank you all for your help and suggestions, it really helped narrow down the problem. Thomas gets the accepted answer though because his suggestion pointed me in the right direction.

sql db problem with windows authentication

Have a SQL Server 2008 db which I connect to the Windows Authentication .. has worked good for 7-8 months .. but now when I come to work today it no longer worked to connect, without that I had done something
Error message was:
Can not open user default database. Login failed.
Login failed for user 'Jimmy-PC \ Jimmy'.
where the first is the computer name and the second is the user. The problem seems to be that it tries to connect to the default database. Have tried to change it without success .. I do not have sql server management tools for sql 2008 but only to 2005, someone who has similar experience? who have not touched anything said over the weekend and it worked last Friday without any problems.
The user's default database is offline. the thing that changed since yesterday is that your database had failed, for whatever reason.
You need to log in with a different account, one that does not have a default database, and inspect the state of the database. If you do not have such an account, then you can use an administrator account. If the administrators group is not granted login into SQL Server then see this article Troubleshooting: Connecting to SQL Server When System Administrators Are Locked Out.
Once you can log in, the only tool you need is sqlcmd.exe, which is installed on your machine. Look into sys.databases, the state_desc column will tell if a database is offline. You can try a to ALTER DATABASE ... SET ONLINE and see if it recovers, but that would be unlikely. Your best choice will be to apply your disaster recovery plan and restore the database from the backups you keep for it.
It is strange that it just stopped working. Have you checked the status of the user's default database? Make sure the database exists and is online.
To find the user's default database run the following command using sqlcmd.exe
select dbname from syslogins where name = 'Jimmy-PC \ Jimmy'
I have seen this error when recovering a system and the user's default database hadn't been restored yet and another time when a database was in "Recovery" mode.
I would also make sure that the windows account is not disabled.
If you find that you need to change the user's default database you can use a T-SQL command, see the following question:
How do I set the default database in Sql Server from code?

Access Log in troubles

Lately there has been a problem running some of our reports in access. Last week(the beginning of the week) we tried to run a reports lets call it A and it kept giving us the log in prompt. Even when the correct user-name and password were entered the log in box would just keep reappearing until cancel was pressed.
I clicked the debug and checked the query. I then logged into the database it is pulling the data from with the same user-name and password and received no trouble. Around Wednesday A was working again, even though nothing was changed. This week A is working but another report B is doing the same thing..
Anyone have any idea what this could be? I'm thinking maybe someone else has the report open? Any help is appreciated.
EDIT: I have narrowed down the error to one linked table that is causing the login prompt. It seems it has the DSN setup but no database specified. So i just need to relink the table..Is there anyway to do this at the GUI level? Also should I leave this question up for future users or just delete it?
Was the login prompt from Access or from Windows? If from Windows, then I'd say that there was some sort of file permission or network access issue at hand. If from Access, then I would say that something in the SYSTEM.MDW that you are using is corrupt or has been reconfigured.
If the login prompt is from ODBC it probably means that the credentials that are being used to access the backend database (per your comments you mentioned it was SQL Server) are either invalid or disabled. (Or it could be as simple as the backend database is/was temporarily unavailable).
If you are using linked tables in Access to a SQL Server it means that an ODBC connection was created and you might try verifying that the ODBC connection is working ( Control Panel, Administrative Tools, Data Sources(ODBC) ). In that dialog there is a place to test the connection.