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

Hi! David Williams <djw@smooth1.demon.co.uk> wrote: >>: 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. 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. THAT is the level of security you are familiar with when you're "grown up" on a mainframe. > 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. Certainly, but not all the security needed. Not all the security you can achieve at several mainframe-SQL-servers like DB2. Why shall we be satisfied in a C/S environment with less security than we had at the mainframe? Bis denne, Volker. ---------------------------------------------------------------------- Ich habe Londo das Leben gerettet, weil im All alles Leben heilig ist. Aber wenn derjenige, den man gerettet hat, diesen Glauben nicht mit einem teilt, hat man der Gegenwart gedient, indem man die Zukunft geopfert hat. (Lenier in Babylon 5) ----------------------------------------------------------------------