Dear Fnds,

In our installation B40c4/SQL2000/WIN2000,

in general the system is overall very slow.

I found the table data autorisation have Read , Not authorised authorisations spread on many tables like tdsls041, tdpur041, tdrpl100 etc.. on fields like cwar, order type etc.. totally 30,000 authorisation records are there.

Will it tax the system, how to find out its load..

will appreciate your inputs

thanks

VISH

Thought this one might get better response in the performance platform.

I'm not sure that I understand the issue though. Are you seeing a lot of attempts to read tables without authorization?

That in itself should have no significant performance implications.

Table data authorisations are killers for performance. Avoid them at all costs on non-key fields. Saying that we have segmented a range of our users from other users on a range of sales order numbers (tdsls040.orno) and project series (tipcs020.cprj) without too much performance impact

hi

hello Frances :
to rephrase my question,
we have defined a lot of table data authorisation;
Eg:
not to be able to access the Warehouses(which are no longer operational) by any user, during purchase, sales and RPL etc.

hello Cole,
thanks,
will authorisation act as a display filter like the
main.table.io:
after read:
if tbl.cwar <> auth.cwar then
skip.io("")
endif

Then it will be really taxing..

wishes

VISH

I found the table data autorisation have Read , Not authorised authorisations spread on many tables like tdsls041, tdpur041, tdrpl100 etc.. on fields like cwar, order type etc.. totally 30,000 authorisation records are there.
Vish,

Thats indeed a lot of settings. We have implemented table field data authorization for tools but not for the application tables and I am on a different BaaN version. But I heard that it helps wrt performance of the bshell.

will authorisation act as a display filter like the
main.table.io:
after read:
if tbl.cwar <> auth.cwar then
skip.io("")
endif
If it acts so then its a performance hit I think it adds conditions to the "where" clause so the invalid records are not fetched.

The problem might be somewhere else on the Oracle tuning, OS parameters etc. Search for other threads about performance and use the bshell options (profiler, dbslog, TT_SQL_TRACE, BLAT etc) to trace the real issue.

Depends on what version of Baan. In Baan 4, it fetches all of the data but doesn't display it. In Baan 5 it modifies the "where clause". Naturally in
Baan 5 you have a better chance of it Not hurting performance - but you sort of have to look at it on a table by table, query by query basis..

In Baan 4 its more consistant, but also you've got a bunch of rules applied to each record before it is displayed..

Dave

I think I add nothing news, but maybe it helps.

Authorisations can become performance killers when:
- checks are done on not index fileds
- many checks are done (like your 30.000 or so ;) ) on index fields

On whatever way you implement it, performance can never become optimal if any of above is implemented.

In older portingsets there where some issues that also could lead to bad performance even when above rules where not met.

Hope this helps,
Dick

dear d'k

if let us say the requirement is:
"No user should be able to use a warehouse code X00 (businesswise now its a dead warehouse which was earlier operational)".

if on index how will I be able to restrict the users:
while creating POs (tdpur040/041 tables)
while creating SOs (tdsls040/041 tables)
while creating RPLs (tdrpl105/100 tables)

if you get any other clues for obtaining the above requirement other than table data authorisation, u r welcome. (I wish there were blokcings, active, non-active fields and functionalities available for warehouses too..like the item signal code....I could have blocked all the locations of the said warehouse but it still allows the users to create PO/SO and all.)

thanks and best regards

VISH

Beside the Baan way, you can try to create a view on the table with the restrictions. Then you don't see the record anymore if that is ok to you. But be very carefull as it interfears with baan components for reorganisation etc.

Kind regards,
Dick