Re: Security options at different SQL-Databases with ODBC - who is best ?

David Williams <djw@smooth1.demon.co.uk> wrote: ... snip ... :>Yes, certainly. But it is not possible right now to build-in all the rules you :>need to provide the security needed. As for DB2 you can (as far as you use :>Embedded Static SQL) enable the user to access tables without having the :>appropriate privileges himself. So you can grant him for SELECT on tables he :>has to evaluate individually with a querytool although he is able to update :>this table from within his application. :> : I don't understand - what stops me writing my own "Embedded Static : SQL" application to access the database and I can get around the : security that way. That is the problem mentioned here. How to : distingush between different applications running as the same user. I think there is a mechanism by which the DB2 program has to be registered as well. That is it has to be compiled by someone trusted to do it. Of course you have to trust someone. If not we can do nothing (unless we encrypt the data in the database - which we don't want to do to solve the security issues discussed now). The key is we do not trust arbitrary users. Still this solution isn't workable as we do want to be able to use regular (dynamic) sql. Otherwise the application becomes far too limited for modern day application requirements. (Think of what you would have to do to support a standard 4GL construct statment via static SQL. I don't even want to think about that.) Se my separate post on a possible solution using pasword protected rolses. ...snip... Nils.Myklebust@idg.no NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company