• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Performance hit when using row security

Does anybody have some experience with performance measurements on XE, with and without row security. I am looking for some information on what the effect is on performance when row security is going to be used. It will be row security on Branchplant (MCU)

Please let me know if you have some experience or information on this.
 
Why would you think there will be any performance degradation? JDE runs an
SQL SELECT to get the rows from the database. Row security will only add
another selection to that SQL. You can see the affect of the row selection
had on SQL in the DEBUG log.
 

antipodes1

Active Member
Hey Arno, Gordon here

You still in Brussels?

Row Security will give you a performance hit, but on the standard of equipment OW is implemented on these days, that hit is pretty minor unless you have a heap of row security.

As always it depends on the system etc, you just have to try it and see.

Gordon
PS drop me an email
 

PAULDCLARK

Well Known Member
To minimise the impact for inclusive row security change the JDE.INI file:

[SECURITY]
Row Security = NO_DEFAULT

to

Row Security = DEFAULT

This ensures that the SQL is performed at the server, and the data is not filtered at the client.

Regards
 

Luke Phillips

Well Known Member
Hi,

As Paul implied above, it is best to be inclusive. If you are not I advise you to convert it - either manually or get us to do it for you automatically.
 

Jaise James

Reputable Poster
I beleive this is not there by default you have to add it in the new release on the enterprise servers. Default is Row Security = NO_DEFAULT, if it not present in JDe.ini
However, I am not sure if it works on the web server. I have a case opened with oracle and so far they only confirmed its meant for windows client. They are checking to see if it impacts web client as well
 

Jaise James

Reputable Poster
According to Bug: 12450377 (SAR 2801522) the 'Row Security' parameter is no longer used. Row security now defaults to the 'DEFAULT'.
 
Top