I’m assuming the person who posted the question has built an application and database that is to be installed outside the domain of the application vendor, at a customer’s site.

Even in this scenario, where the database is installed at a customer’s location, I think it would be a rare case, if ever, where you would want to completely prevent access to your database. It can negatively affect customer relationships in several ways and attempts to use security features for a purpose other than a true concern for the security of the customer’s data.

Do you not want your customers to see your bad database design? Are you trying to ensure that you are the only one who can help them when things run slowly? Are you trying to prevent your customers from writing their own queries or reports? Do you think they’re not smart enough to write good SQL? (Maybe they’re not, but is restricting database access really how you would solve that problem?) You don’t want to insult your customers; you want to empower them and work with them, ultimately improving their success.

Except for the tiniest of databases or those of the simplest design, there is no scenario where you want to cut off complete access to a database, because every database requires maintenance and if it’s located at a customer’s site, then they’ll need access to the database for maintenance. This can be done by the SA account, but should also be allowed by the dbo – the person(s) responsible for maintaining that database – under least-privilege best practice.

If your application is smart enough to replace a DBA by monitoring and performing necessary maintenance on the database, then you’re smart enough to make and use your own proprietary database management software.

If the real concern is about customers reading your “proprietary” data and not about them seeing the design of the database, then consider using password-protected encryption within your application – read and write only encrypted data.

If the concern is about reading the logic (the SQL statements) within a stored procedure or user-defined function, then consider using the CLR equivalent and obfuscate the .NET code. But that’s only make it difficult, not impossible, to read.