custom record privileges. help!

[raingirl]

I want to limit record access in a table for current / archived records.

I created a global and one (indexed calculation) I'll call STATUS that traps whether the record should be current or archived.

Then in record access, I limit viewing to global=STATUS.

Works fine, limits the records correctly. However, it is slow when processing finds (real slow). I can process the same find with full access and it is lightening quick. I am processing finds on indexed fields too. Argghh.

I really want to keep current and archived records in the same table and limit record access but the more records I accumulate, the slower it is going to get. Any suggestions? What am I doing wrong?

-Marcelle

[Steven H. Blackwell]

Try making the test to be STATUS="current" of whatever the viewable option is supposed to be. RLA in browse mode is not the speediest item ever known, especially on OS X.

HTH

Steven

[Ender]

You might consider enforcing the visibility with scripts and relationship filters instead. With your Status field, you can limit the users finds to only those with Status="Current", and you can use it in relationship criteria to filter the relationships to this table.

[raingirl]

What was nice was that you could just change the global field from "Current" to "Archived" and then perform a find so the user doesn't know anything happened. Same layouts, same table, different view. Its just their finds are slow.

Are you saying I should base the layout on a filtered TO? This hasn't proven very effective for me.

I tried what what you said about setting the status="Current". Works fine after I removed the global field element. Does a global in the calc. slow things down? Also, doesn't seem to like a case statement where if you change the global, it shows different records. Works great except the users finds are SLOW.

[Steven H. Blackwell]

As I said, RLA in Browse mode, especially on OS X, is not really speedy. The global is--in essence--an unindexed search.

Steven

[raingirl]

It is slow even without the global. Is RLA not a good way to build an interface? How do I put all students in one table but only show current? Same with grades, etc. Will this get slower in a multi user environment?

[Fenton]

I think that's what they are saying (and me too). RLA is not a good way to implement a "toggle". Because the toggle implies a global field, and that makes it slow. RLA is more of a security feature, to be used only when really needed; because of the speed hit it implies. And yes, it gets much slower in a multi-user environment.

There are different ways to do what you want. You could use a (big) portal, showing only current. Or you could create a dedicated Find layout, where the global toggle could be implemented into the executed Perform Find. The Find layout could even be shown in a small new window, if that's all you need.

[raingirl]

What you are saying would work for finds, etc. but still makes a crufty interface. So does that mean that I need to create another table for archives? When someone wants to view archived students, grades, etc., I need to build more layouts and reports.

Even when I tried the suggestion of removing the global and using status="current" (indexed), the finds were still slow. There should be a disclaimer on RLA because I don't see much use for it.

[Steven H. Blackwell]

RLA is now Server based--to be precise row level access calculations are performed on the server and only the Rec ID's of the matching sets are returned. This speeds things up considerably.

However, when you're using globals you're using unstored values. Or to be most precise you're using values that belong to the table, not to the record.

Steven

[Fenton]

It is certainly a little more work to build a Find layout, but I don't know that it has to be "crufty" -] A carefully controlled new window, or maybe only a dialog box (if your Finds are very simple) is not that bad.

It seems as if you are talking about a lot of records. Otherwise I wouldn't think that: status="current" (indexed) as RLA criteria should be slow. Are you sure Status is indexed? But in any case that won't work, because a privilege set with that RLA could never see non-current records.

It would not be that difficult to build an archive table(s). One thing that occurs to me is an "inactive" students table, which would be ONLY students who are not active. The Grades, etc., are their own tables, not split or archived. All viewing and navigation is from Students or Archived Students. That alone may solve the problem.

At first it seems odd, but you almost never deal with inactive students, so they are, in a way, a different entity. Of course then you need a method to move students back and forth (and when?), search in both tables if needed, etc.. Much more trouble and more complex than a dedicated Find layout for sure.

[raingirl]

I am now using indexed calcs. (status="current") and the hits are still slower than full access. I am still in development stages and have serious doubts about implementing an interface like this in a multi user environment. From the previous post, I got the impression that RLA is for security and not necessarily for cleaner interfaces. I just feel like I am back to where I started in fm 6. Creating archive files to hold archived info. yuck.

[raingirl]

I am at the point of creating separate tables for Inquiry and Student Archives but that means building a whole interface around archived records. I would have to duplicate reporting,stats, etc. I was hoping to avoid this.

[Ender]

In my opinion, this idea of creating copies of tables to hold archives is a poor design. It forces you to duplicate your development effort whenever you add a field or change a report. It also introduces data integrity problems because of the need to move records back and forth.

You should reconsider a solution that uses scripts and relationship filters to allow/deny access to particular records. I do this all over the place in my solutions.