How do I query SQL Server's built in configuration functions (e.g., @@SERVERNAME)?

The title says it -- I want to issue the query "SELECT @@SERVERNAME AS ServerName" and return the results to my app. I need to get the server name from the database so I know what server I am connected to at runtime.

What I am trying to accomplish is prevent our production line machines from running code that accesses our development server instead of the production server. Yes, we did that. My idea is to query the database from code and refuse to run if we hit the wrong one.

This is a fail-safe method, meaning I am still looking for a good way to make sure we never release code that might actually do this. Some suggested methods I have heard are to use Machine.config (which I am not very familiar with) or to use an automated build process (which I don't have time to set up at the moment). The automated build is by far the best idea and one we have been talking about for months, but it just hasn't happened yet.

So, if you have ideas I am more than willing to listen...

Thanks, Dave

Use ADO.NET. Seriously, LightSpeed just doesn't add any value when you want to do something like this -- there are no objects to map into, no classes that contain mapping information. Just issue a good old fashioned ADO.NET command, using IUnitOfWork.PrepareCommand() to run it over the LightSpeed connection:

using (IDbCommand cmd = _unitOfWork.Context.DataProviderObjectFactory.CreateCommand()) {
  cmd.CommandText = "...";
  return _unitOfWork.PrepareCommand(cmd).ExecuteScalar();
}

Regarding the broader issue, this is a bigger issue that might be better raised on a larger forum. One obvious thing is to understand where dev server references could creep into your code. E.g. if the concern is that somebody might leave a dev server name in a config file, write a little script (or a quick C# console app) that checks all config files, and run it as part of your deployment checklist. The ideal solution is indeed to automate the deployment process, so you could run a config file scrubber as part of the installer. And honestly, automating many aspects of deployment is not as hard as it sounds, and pays off really quickly. A few batch files, maybe a few VBScript files calling WMI or other automation interfaces to set up app pools, etc., the odd ten-line C# console app for when you need a bit more smarts: even if you have to leave a few things to be done by hand, it is still a huge time saver and eliminates many deployment errors. Seriously, spend a few hours going over your deployment procedure and seeing where there are command line or WMI equivalents, or where you could write trivial console apps to automate them: you may be surprised how quickly you can get something working!

Thanks Ivan, that's the syntax I was looking for.

I would not want to deploy production code and expect this to be my only method of keeping things straight -- it might make us look bad (worse?) to the end user when they have to call us when the app refuses to run because of something we forgot to do. However I do plan on doing this check as a fail-safe just in case the

So we do need to do a little automation. When I came on board this project there was no database and the app was (is) being deployed using Microsoft's ClickOnce. I would really like to get away from that...