Curious about speed of browse record privleges

[ibiubu]

After implementing a calculation for browse records privleges I noticed a HUGE slowdown when users open my hosted database file. I assume this is because when the database is opened there is a initial find taking place to find records with which the user has browse privleges.

I only have about 300 records in my database file, and I cant imagine how long it will end up taking to open the file when there are 3000 records.

Is this just the nature of the beast. IF so, YIKES! How do users deal with this? I cant imagine a solution with 30,000 records. It would take an ETERNITY to open the file if there are any browse record privleges set.

LR

[Anatoli]

I believe it was already discussed in detail

[LiveOak]

It's not a find that is causing the delay, it the evaluation of the calculation specified to allow browsing. This calculation will be especially slow if it uses summary fields or a calculation based upon related field.

-bd

[ibiubu]

Calculations based on a related field...that is good to know. I think that one of my calcs is based on a related field. This is probably the reason for the drastic slowdown.

Thanks for the good tip. I guess I will have to re-think how my privleges for my browse records works so that I dont have to use a calc based on a related field.

Would there be a big speed difference between these 2 browse record calculations:

1) user login::user = user

My main file is accessed by first logging into the "User Login" database file. A button there then takes them to the main database file where the browse records privleges calc looks at that user name from "User Login" and compares it to the user name in each record of the main file they are opening...so as to determine which records can be accessed.

2) gUser = user

I could have a script in "User Login" that when clicked on, goes to the main database, sets the field gUser (a global field) to match the name from "User Login." Then the access privleges would be comparing the gUser field to the user field for record access. Doing it this way avoids using any fields that are related. But I dont know if this way will provide a speed increase over the first way.

LR

[trevorg]

I think I have given up using that feature. I've tried many different ways using it, and still could not get acceptable performance.

I tried the simplest evaluation possible. Browse_Field = 1

No calculation, no relations, just the number 1. It still took forever for that evaluation. I have 300,000 records in my DB. (I tried it indexed and not indexed with no difference in performance)

I don't think it matters how that feature is implemented, just the fact it's being used is the problem.

I think the only way to even remotely make it useable it to architect the entire DB based on scripts to always come up with the found set the user is allowed to see. Then use the browse security to absolutely enforce it. (basically a second security measure after the scripts have done their job first).

If you solely rely on the browse security alone. Then you're in for a nasty surprise. (as some have found already on this forum, me included)