Post reply

troubleshoot connection issue - what is issuing the login request?

  • July 6, 2015 at 2:12 am

    #305544

    So I've removed db X, and I get periodic login failures in the SQL error log because db X does not exist. My app owners assure me this db is not required. I don't like these errors in my log and would like to be able to go back to the app owners & say change this db parameter on process Y.

    I can see the username, timings & host ip in the SQL error log.

    I've logged onto the box, gone through all services with this username and can see nothing referring to db X.

    I've run profiler to capture errors but this presumably only does so AFTER login as it's not showing me failed logins.

    Is there any way to get any further information on which pid / process is at fault here?

    Thanks.

  • July 6, 2015 at 2:27 am

    #1810368

    You could use a server-side trace or an extended events session to capture the login failed events (profiler could also work if this is not a production instance). Have you tried that?

    -- Gianluca Sartori

  • July 6, 2015 at 5:36 am

    #1810399

    Check the default database for login in the login properties.

    Change it to master or tempdb.

  • July 6, 2015 at 6:21 am

    #1810410

    mssqlsrv (7/6/2015)

    Check the default database for login in the login properties.

    Change it to master or tempdb.

    This wouldn't solve the issue: there's an access to a database which is not needed in the application, so the real fix is removing the calls to the database rather than pretending that they're not happening.

    -- Gianluca Sartori

  • July 6, 2015 at 6:26 am

    #1810413

    Just a thought - can you see if any application related .exe is running? I have seen a handful of issues in my environment and sometimes you can't believe what you see. The last one I saw was login failures coming from each individual user laptop and we had a domain migration - so in the end we have to reach out to those X users to stop one of those old stupid service.

  • July 6, 2015 at 8:14 am

    #1810452

    Thanks all for taking the time to reply.

    spaghettidba spot on. I'd been using the profiler to trace errors (which yielded nothing) but hadn't realised there was a separate failed login category which gave me a pid. From there I could see that it was a SQL agent call - a job that no longer had a database, but had previously been calling a proc in the now detached db X.

    Now I can go to the app guys and see how they want to proceed armed with the right info.

    Much obliged!

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply