Performance hit when using row security

[Arno_Klijnman]

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.

 

[gary_mogilner]

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.

 

[CHo]

Have you implemented row security? Has there been a performance degradation?

 

[antipodes1]

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]

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]

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.

 

[johndanter]

Is this INI file setting in the newer releases of E1?

As I can't find it in mine

 

[Jaise James]

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]

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