Need Solution for SQL Server

>> Our SQL server has  proprietary information that we do not ...


When you say proprietary information are you referring to stored procedures and how your system operates?

Could you compile the sp's into DLL's and then make them xp_MyProc?

No we cant.  Yes the stored procedures, table structures, etc....  We want to prevent any reverse engineering.

There is really no way to do it. Especially once it at the remote site.

SQL Server has to have a database owner that is local and can't be prevented from seeing the structure and data in the tables.

AS has already been pointed out, having it on a local intranet is going to, basically, require exposing the database.  The only solution that I can come up with is to, in effect, host the database locally instead of on the internet.
In other words, suppose you set up a server and the database on site but retain full control over and the only non-programmatic access to the database and server.  (Of course, you would need to escrow  the SA name/password, etc., in case you and your company get squashed on the freeway. ;-)  The idea being that you will maintain the server and the database via remote connections but it will be, "in-house" and on their intranet for all practical purposes.  
Of course, since you will have additional expenses involved in dealing with the remote locations for the servers and databases, you will need to charge a bit more for the services but, if the companies are that paranoid, they will probably pay for it.  If they opt not to and, instead, opt for the secure internet rather than intranetoption, then you aren't out any more trouble than preparing the proposal. ;-)

Let me try to be a little more clear.  We have an internet site which will still be available for customers.

It is the customers who want an intranet solution that we are trying to address.  They will not use our functioning internet site.  We need to implement our code and dbase on their intranet.  We can take care of the code.  The issue is SQL Server.  We do not want them to have internal access to it if it is on their site.

I would think that as long as you did not provide them with a Windows login nor a SQL login that they shouldn't be able to Connect the the dbs to see them?

Additionally, if you provided even 1 user to have a SQL login, the DENY option in the permissions is a very powerful limiting option to keep people out of what you don't want them to see.  But first, I simply wouldn't give them any credentials to connect in the first place.  Let your code access the dbs only using a SQL login which SHOULD BE encrypted in your code or in the config file for the code.  Then just don't ever give those credentials to your customer either.

have you looked into the WITH ENCRYPTION options of stored procedures, functions, views, and triggers?  that will let them work but not be viewable or editable.

@CipherIS
Let me try to be a little more clear.  We have an internet site which will still be available for customers.
That was not precluded by my recommendation.  
To restate as briefly as possible:

1. Install the Database on a server at the customer location;
2. Do not provide any logins to the customer;
3. Only allow access to the database's data via the application which has the only "local" access to the database;
4. You and/or your company will have maintain the server and database via remoteing into the box (which, of course, will mean that the custoemr wll need to provide you with the necessary access through their firewalls, etc.).

Thus, you maintain your security on your database and the customer maintains their security on thier world.
Whether or not you have a version of the database set up on one or more local sites in this manner has zero impact on your internet site . . . although it does somewhat complicate the application and database maintenance.

However, if the customer is tech-savvy or hires someone who is, then what jimpen stated would seem to be true.

Thx

Glad to be of assistance. May all your days get brighter and brighter.