*snip*
>Basically the DB is being ported AS IS into SQL, so few if any of these issues are being addressed. In addition, there's nothing to prevent client from giving users access to the Query Analyzer and allowing them to muck up the data at will. So in a sense we can't take advantage of SQL security.

That's the perfect place for it. If they want users to be able to run ad-hoc queries then give them the user ID and password of a user that has Select rights on everything. But that user doesn't have any INSERT, DELETE, UPDATE or EXEC rights on anything.

As David said, the middle-tier object would have the necesasry user ID and password to update the data. You could even write this object as a DCOM server running on a physically secure box with the appropriate user authentication setup. The user ID and password could be stored in the registry of that locked box and gifted users wouldn't have access to it.

In my mind, this is a valid use of resources/technologies that are already at your disposal. The other way is more of a kludge (IMO).