RaSQL.com » troubleshooting http://rasql.com Ra Osolage's SQL Server Blog Fri, 13 Aug 2010 17:25:15 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 Helping Users Test Database Connections http://rasql.com/2010/08/helping-users-test-database-connections/ http://rasql.com/2010/08/helping-users-test-database-connections/#comments Fri, 13 Aug 2010 17:25:15 +0000 Osolage http://rasql.com/?p=18 Continue reading →]]> From time to time, I have users that will say something like, “The application can’t connect to the database.” Often times they really don’t understand HOW the application’s connection is configured or established. In times like that, I find it useful to have them try to connect to the database outside of the application. Of course, I have them attempt to establish the connection while logged into the workstation/server where the application is supposed to be running.

I’ve found the easiest way to have them test the connection is to use a UDL file. You can read all about them here. Essentially, it’s just a little text file that you put on the harddrive of the machine where you’re testing the connection. The instructions for creating a UDL file are included in the page that I’ve linked to. Just have the user follow the instructions to set the connection parameters and have them hit the “Test Connection” button. If the connection works, then you know it’s something application specific that is problemmatic. If the connection fails, you know it’s either something with the server or something with the SQL Server.

What techniques do you use when troubleshooting database connections?

]]> http://rasql.com/2010/08/helping-users-test-database-connections/feed/ 0 Finding Which SQL Server Instances Just Restarted http://rasql.com/2010/01/which-sql-instances-restarted/ http://rasql.com/2010/01/which-sql-instances-restarted/#comments Wed, 27 Jan 2010 16:05:17 +0000 Osolage http://rasql.com/?p=6 Continue reading →]]> Today, i’m troubleshooting an issue with the cluster where our SharePoint databases are housed. I got an alert from SCOM saying that one of the clustered SQL Server instances had failed. (Thanks SCOM a.k.a. OpsMgr for letting me know!)

Anyways, I wanted to know real quick which instances had actually restarted. Quickest way I knew was to filter the Windows application event log down to EventID 17162. Turns out, SCOM was right. Only one instance reported that it had been restarted.

Now that I know which instances have restarted, I can begin the in-depth research…

Consequently, I’ve found that you can track shutdowns of SQL Server by EventID 17148.

]]> http://rasql.com/2010/01/which-sql-instances-restarted/feed/ 0