User-friendly tools for retrieving data from a SQL Server database

We have several SQL Server databases containing measurements from generators that we build. However, this useful data is only accessible to a few engineers since most are unfamiliar with SQL (including me). Are there any tools would allow an engineer to extract chosen subsets of the data in order to analyze it in Excel or another environment? The ideal tool would

1. protect the database from any accidental changes,
2. require no SQL knowledge to extract data,
3. be very easy to use, for example with a GUI to select fields and the chosen time range,
4. allow export of the data values into a file that could be read by Excel,
5. require no participation/input from the database manager for the extraction task to run, and
6. be easy for a newbie database manager to set up.

Thanks for any recommendations or suggestions.

First off, I would never let users run their own queries on a production machine. They could run table scans or some other performance killer all day.

We have a similar situation, and we generally create custom stored procedures for the users to "call", and only allow access to a backup server running "almost live" data.

Our users are familiar with excel, so I create a stored procedure with ample parameters for filtering/customizations and they can easily call it by using something like:

EXEC YourProcedureName '01/01/2010','12/31/2010','Y',null,1234

I document exactly what the parameters do, and they generally are good to go from there.

To set up a excel query you'll need to set up the data sources on the user's PC (control panel - data sources- odbc), which will vary slightly depending on your version of windows.

From in excel, you need to set up the "query", which is just the EXEC command from above. Depending on the version of Excel, it should be something like: menu - data - import external data - new database query. Then chose the data source, connect, skip the table diagram maker and enter the above SQL. Also, don't try to make one procedure do everything, make different ones based on what they do.

Once the data is on the excel sheet, our users pull it to other sheets and manipulate it at will.

Some users are a little advanced and "try" to write their own SQL, but that is a pain. I end up debugging and fixing their incorrect queries. Also, once you do correct the query, they always tinker with it and break it again. using a stored procedure means that they can't change it, and I can put it with our other procedures in the source code repository.