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

David Williams <djw@smooth1.demon.co.uk> wrote: :In article <53ua04$jc@knot.queensu.ca>, guest <?@?.?> writes :>In <53qrcr$8dk@nntp.idgonline.no> Nils.Myklebust@idg.no (Nils Myklebust) :>wrote: :>: Micorsoft seems to believe that free access by everyone to all data in :>: all databases is the best situation for everyone. :> :> No comments. :> :>: There is *no* mechanism built into ODBC to protect any data from free :>: manipulation by any user *if* that user has access to some application :>: that can do such updates. : Correct but this level of security should be handled by the database : server. You can grant/revoke prvilieges to update/insert/delete/ : select from each database table in turn for each user in turn. This doesn't solve the problem at hand. : Also you can have database triggers/stored procedures which can : perform security checks before allowing database modifications. This does "solve" the problem, but limits you to do all updates this way. Not very friendly and may create a lot of problems. This has been discussed recently, and don't need too much repeating now. :> the frame of ODBC. But all of these are implemention issues(and :> technically can/already easily be solved) not a problem of MS ODBC, :> ANSI CLI, X/Open DBC or SQL in general. :> :> -g :> :> : Most security issues have already been solved. Use OnLine/Secure : a B1/B2 rated database server which also requires a B1/B2 rated : operating system and ties it's security to that of the operating : system. All security is handled on the server machine. Well, yes. But I think the the problem discussed is one of those who are not "most security issues". Or does OnLine/Secure have a way of distingushing applications comming in over the same communications protocol (I-Net or ODBC) from the same klient using the same loginname and password? 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