Horst G Reiterer wrote:
This is not entirely correct, it was there and when the module it lived in got re-written it was descided not to spend money on re-implementing it as it was seen as being somewhat sub-par.You're basically right. The situation here however is that the feature has not been requested - it was there and has been removed.
Hmm, yes, the internal naming is sort of strange (like it could have been written by a demented cat on a keyboard), Daniel did publish a guide of sorts that tried to explain it...I have absolutely no problem with that, in fact I'm eager to do so. Unfortunately - as you know - that is not necessarily a truly straightforward thing to do because of the current language-mix and internal naming conventions.
> Re-implementing the PERMLIMIT, to name a specific feature, would
> require a broad understanding of most parts of the code.
One thing that I have to wonder about is if it would be possible to implement this outside of the DBMS, you will not be able to catch truely Evil users before they go over their quota, but if you are willing to live with a slight delay in enforcement then you could get away with having a deamon watch the database and lock out users who are above quota.
Having a daemon outside the database also means that you could start sending warning mails, console messages or ICQ messages to the useres who are at 90% of their quota before locking them out.
I don't know how to get the exact byte-size of all rows of a table, but for tables that don't have LONGs you can calculate the row-size from the metadata and do a count(*) on the table to get the size...
As far as I can see you can solve your problem without having to touch the database code at all and you will get more detailed control over enforcement and unless you allot very small quotas to your users then they can't stuff in data fast enough to go much over quota before being stopped.
The old PERMLIMIT wasn't perfect either, because you could have a user fill up the LOG with a huge transaction (as far as I know) or otherwise make life hard for other users, I think the point is that you can't expect to contain the users who are out to get you.
--
Regards Flemming Frandsen - http://dion.swamp.dk
PartyTicket.Net co founder & Yet Another Perl Hacker
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general
