Click Here to get the Code

Run it then in the results pane you’ll see all the commands ready to be copied and pasted into the query window.
Nice!

Finding out the data and log file locations in SQL Server can sometimes be a little fiddly. With that in mind, I’ve been looking for a way to list the files used by each database. Whether for system or disaster recovery documentation, it can sometimes be handy to have this kind of info available to you.

Finding out where the mdf (database file) is can be pretty easy. Its held in the Master database somewhere. Its only when you want to check where both the mdf and ldf (transaction log file) are stored that it can get a bit tricky.

The way I’ve been doing it involves a cursor that creates a new line in a temporary database for each database you have on that particular server. Ordinarily to get where the database and log files are kept you’d use a query like the one below:

EXEC sp_helpdb ‘master’

What I’ll be doing is something that works similar to this but basically does it for all the databases in one command.

Get the name of the first database

Query the database for its file locations, writing them to the temporary database

Get the name of the second database…..

Etc

So, here goes with the actual code: 
 

Click Here to get the Code 

I don’t have any databases that use more than the primary filegroup so I’m afraid this won’t help users that may be doing that.

For us simple people however, this will give you a report that can be used in disaster recovery docs and the like for years to come.

Windows comes with a number of Open DataBase Connectivity (ODBC) drivers already installed. Things like Access and SQL server are easily contactable from the get go, its only when you look at database systems from other suppliers that you need to think about downloading drivers.

Products such as Oracle, MySQL, PostgreSQL and the like will require their own drivers installing before they become an option for DSNs. When you think about it, it kind of makes sense. Why should Microsoft try to write the driver when the one from the manufacturer will do the job much better and will probably go through many incarnations before the next Windows release?

I’ll talk you through how to set up a vanilla, ready salted, sorbet of a DSN setup that will hopefully point you in the right direction if you’re using other clients.

OK, here goes:

• Go to Control Panel
• Double click Administrative Tools
• Open Data Sources (ODBC)

There are a number tabs available to you at this juncture, I’ll be concentrating on System DSN in these instructions. Please see my notes at the end of this post for a little further information about the others.

• Click the System DSN Tab
• Click the Add… button
• At this point you must choose the ODBC drive you’re going to use for the DSN, select SQL Server for now
• In the Name box type the name you want the DSN to have
• Type a meaningful description in the Description box
• Drop down the list at the bottom to select the server you wish to connect to
• Click Next

At this point you’ll be asked about how you’d like to connect to the server, you’ve got two options:

Windows Authentication uses the credentials of the user that’s currently logged in to the PC. Its OK from most connections as long as the database administrator has set up the user on the SQL server.

SQL Server Authentication is used when you’d like to connect to the server as a SQL Server user  account. It doesn’t care who you’re logged in as, you’ll authenticate as this user. In order for this to work, your dba will need to have created a SQL user and be running the server in question in Mixed Mode Authentication mode.

• Leaving the authentication as Windows for now, we’ll move on. Click next
• Now you have the option to change the database you’ll automatically connect to and some other settings to do with ANSI identifiers and nulls, ignore the lot and click Next
• At this screen you get the options for logging, encryption and languages, leaving these as they are you click Finish and away you go.

This is the most basic form of connection you can have. Using this you can create linked tables in Access, reports in Crystal Reports, use pass through queries, the lot!

Notes

Types of DSN – There are three major types of DSN: User DSNs, System DSNs and File DSNs.
User DSNs are used to create data sources that only that user will need. If you have roaming profiles enabled, they’ll follow the user about too.
System DSNs are machine specific and don’t care who’s logged in. They’re handy for things like reception desks and so such where the user can frequently change but the information available must always be there.
File DSNs are simply files that hold DSN information.

OK, lets start with the scenario that you want to access a stored procedure (sometimes called a sproc) called sp_this_one on a SQL Server somewhere in your organisation.
In order to run this sproc you’d normally issue the command EXEC sp_this_one in Query Analyser or some such tool.

In order to run this sproc in access, you just need to make a pass-through query with that exec statement. Easy as.

Assuming you’ve already set up a Data Source Name (or DSN) to your SQL Server’s database (don’t worry, I’ll be writing about how to do that in another post) the process is straightforward.

1. Create a query
2. Close the Tables box
3. Go to the Query Menu
4. Select SQL Specific > Pass-Through Query
5. Click the Properties button on the toolbar
6. ODBC Connection String
7. … button
8. Select data source

And that’s it. All you need to do then is type into the query window the command you’d like to pass through to the server. In our case EXEC sp_this_one.

I realise I’ve been using some rather broad strokes in these instructions, please feel free to email me if you’d like a slightly better description.