> b) is what i worry about the most, because i might have to grant > access for some data to some "untrusted" users ...This may not be a good idea at all, "untrusted" users are commonly also remote users that you have little, so if you should want to change the schema then upgrading all these untrusted clients could be very hard...
I'm talking about a web app, and i might have to grant access to some base-tables to another web-developer whos app runs on the same server and which uses the database.
Maybe it would be a good idea to write a layer inbetween the untrusted users and the database?
What do you mean with "layer"?
OK ... but even if i the other programmer isn't stupid in any way, he will never notice that he created a foreign-key with "on delete restrict" until i notice a failing delete-operation.SAP DB can protect you from some stupid user doing "select * from huge,gigantic" afaik, but it can't protect you from bad programmers who do lots of little table scans, forcing these people to use your interface would also help ensuring that they don't go and do stupid things with the database...
A simpler solution that solves your references problem could be to not grant untrusted users access to create tables at all, but to have them request the creation of tables / foreign keys from you and then do the creation yourself.
good hint.
i should have known that there is table with the foreign-keys, but am i abled to define a trigger/constraint on that table? that way, i could insert a rule that the specific user can't create foreign-keys with the "ON DELETE RESTRICT" attribute.You could also write a simple script that keeps an eye on the "foreignkeycolumns" table and whenever something changes check that it's allowed (between untrusted tables, trusted tables or that the "on delete"-clause is ok if it's a untrusted table referencing a trusted one), this would solve your problem if it ever happened, but it could leave a short window where you might see trouble.
But will that brake anything of the SAPDB internals?
Thx
Sven
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general
