August 10, 2006 at 4:58 am
August 10, 2006 at 6:23 am
If you keep your stored procedures as scripts then you can use SQLCMD to run those scripts and pass in a variable to append to the CREATE PROC statement.
That variable would contain WITH ENCRYPTION.
In your own environment your variable would be empty, but when installing on a client's machine you would set it. That way one script caters for both audiences.
August 10, 2006 at 7:07 am
Problem is that it doesn't stop them from editing the stored procedure, it just encrypts the stored procedure text. They could edit the stored procedure and replace it with completely different text.
If you're more interested in hiding your code from them then encryption will work nicely - even this can be easily undone though.
You could implement a DDL trigger (if they let you do that on their server).
Bottom line - if the server belongs to the partner and they have sysadmin rights to their own server then there's not much you can do to stop a determined sysadmin.
August 10, 2006 at 2:06 pm
When I worked for a company supplying solutions the attitude was altering the source code violated any support contracts.
It was a business issue not a technical issue
August 10, 2006 at 10:58 pm
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply