Thanks for the response.
The "configuration" data I have in this singleton table is a few things:
1.) major/minor/build/release version of my database. We use this for our database update utility to step-by-step, walk the database admin to the current version. We really need to keep this in the database, as it's the key to running a structural update on tables of the database.
2.) Some global settings that are configurable via a customer accessible web-interface (a person who's not a system admin...so they don't have access to the web.config file). These are also one-per-system.
I could have gone the other direction: Make Name/Value columns in the table, then fish out the values by name. But that feels looser than a singleton table. To tighten that (in the database), i might would have a unique key on "name", and a trigger to check that it's a valid name (putting all valid names in the trigger).
But either way, I'd have to modify the database for any new config value...so I want to go with adding a new column (when add a new config value)...and making it a singleton row.
I believe I can do as you say and make a "lock" column with a known value (like an "x" in the lock column), making a unique constraint on "lock", and a "must be value 'x'" constraint.
But I'm gathering in LLBLGen, there's no recognition of a database table singleton. No big deal...just an extra line or couple of code to make it solid using the GREAT llblgen generated code. (llblgen is such a great tool!!!)