Jump to content

Curious about speed of browse record privleges


This topic is 7815 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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.


Link to comment
Share on other sites

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.


Link to comment
Share on other sites

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)

Link to comment
Share on other sites

This topic is 7815 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.