|
|
Posted by Erland Sommarskog on 11/06/05 16:38
helmut woess (hw@iis.at) writes:
> Yes, everything has two sides. But i never touch foreign stored procs for
> repairing something! If a customer has a problem with a software not from
> me, then he has to clear this with his vendor - or he can change his
> software and work with my solution.
I think there are a lot of people out there who can tell you horror stories
of third-party vendors that for one reason or another do not offer support.
The company may folded, or the support fees is simply outrageous.
> Yes, i know, i don't like extended stored procs too, but i know no other
> way to secure a stored proc. And disassembling is much more harder then
> reading a clear text. I need not 100% security, but it should not be sooo
> easy to decrypt the source.
>...
> I want to prevent damage before it can happen because i have not the time
> nor the money to bring an action against somebody.
Look, if someone is dead set on stealing your code, disassembling is not
going to stop him.
In older versions of SQL Server, SQL Server did in fact stored some sort
of "object code" in sysprocedures. This was abandoned with the re-
architecture in SQL 7. This also resolved some gotchas that came with
the old arrangement and the final result is a cleaner architecture.
--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp
Navigation:
[Reply to this message]
|