Re: Security and the ODBC

john@rl.is wrote: :The only solution to this problem is to give only read access to the :users and give the maintenance application it's own userid, e.g. :"program". The application begins by connecting to the database with this :userid and password (which users are unaware of). Other odbc connections, :whether direct or via Openlink, would be with normal userids and only :read access. : :If you think about it, you have all your business rules in the :application but these rules should be in the realm of the database :because it is being opened to access from other clients. Either you move :those rules into the database via constraints, triggers, stored :procedures etc, which is very impractical, or you effectively move your :application into the database realm by giving it a secret userid and :password. One major issue here is that every application would have to be reprogrammed to handle this. Any solution that involves using another username than the real username of the user (the one the user types in) also has the significant problem that the user function of sql no longer is particularly usefull. We at least want to know what users did what. Our users have demanded this. With the above solution the applications would have to supply the real user name. I dislike that situation. In many cases we have used default user in the creation of tables. That would no longer be meaningfull, and there are several other problems. Nils.Myklebust@idg.no NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company The Informix FAQ is at http://www.iiug.org