Help setting up multi user application

[aldipalo]

Can anyone suggest some reading material or sample files showing how to properly set up a multi user system? I've tried setting a User Table in front of all other tables, but, it's not working the way I thought it would. My problem is I want to separate what the user sees so he/she isn't viewing someone else reports, activities, etc.

Whenever I try to set up Accounts and Privileges it never works the way I thought it would so I really need some good examples and reading material so I can understand the whole concept.

Any suggestions?

TIA

[aldipalo]

Come on folks. Somebody can give me a push in the right direction. Pleeeease.

Edited March 5, 2009 by Guest

[bcooney]

All I could do is start a list of considerations for you. I don't know of a good resource or a multi-user best practices white paper. Picking up my copy of Using FM 8 (haven't bought a new one), there's a chapter on Sessions, Record-locking and Record-level Access Privs. All things to understand when building a multi-user system.

[aldipalo]

Excellent. At least it will give me some parameters. Thanks Barbara!

[bcooney]

You're welcome. All I build are multi-user systems, so I can't think otherwise. Brainstorming...

1. Have a zz_AccountCreated field in each table. Then you'll be able to restrict record access based on whether the Get(AccountName) = zz_AccountCreated. If Account names change, I sometimes go with zz_StaffID_Created and use an autoenter calc of g_StaffID. I Find the staff record by searching for a match in Staff for Get (AccountName) in an Open Script, then set g_StaffID.

2. Remember, every user has their own global field values. So, you'll need to populate them in an Open Script. If an Admin changes a Pref field, you'll want to broadcast the new pref. I don't build relationships to Prefs, I publish Prefs to globals. So, I have a separate Update Globals script. In it, I set a trigger field. This causes all the globals to reevaluate because they use auto-enter calcs evaluate always and allowed to replace existing value. The Update Globals script runs every time someone navs to the Main Menu. You could use global calcs=pref values, but I'm not a fan of global calcs.

3. I have a ssCheck Rec Lock script. Anytime I'm looping thru recs and setting fields, I use this subscript to be sure I own the record. Beware of Replace Field Contents and any routine that affects more than one record.

That's all I have for now. This thread probably exists somewhere...

Edited March 5, 2009 by Guest

[jfcarbel]

I found this and had it saved, but I do not recall where or what blog or forum post I have grabbed it from (apologies to the author, whomeever you are).

Rather than trying to modify the record and then test for an error, you're better off trying to gain control of the record without modifying it using the Open Record/Request script step. For instance, the following script shows the basic construct for a record-locking-aware script:

Set Error Capture [On]

Open Record/Request

If [Get(LastError) = 301]

Show Custom Dialog ["Record Locked"; "This record is locked!"]

Else

#Place any script steps here you want to occur if the record is open

End If

Testing whether the current record is locked is simple, but the task gets significantly more complex when attempting to modify multiple records. For example, the Replace Field Contents script step or a record looping script attempt to modify multiple records in succession. If you have a few Guests on the network, chances are the modifications will occur without a hitch. When you start to add more users, the chances that one or more records are locked increases.

So, what can you do in this record-locking scenario? There are complicated transaction techniques you can employ, but I like to tailor the solution to the need. For instance, say you want to mark all the records in the found set so you can search for the marker and reconstitute your found set at a later date. Of course, this process could cause record locking on more than one record, which you could attempt to track. Instead of writing a value to the records, grab the serial number from each record. Reading a value from a record doesn't require it to be unlocked. In this way, you can gather all the serial numbers and store them in a return-separated list. To restore your found set, simply use the serial numbers in a multi-key relationship along with the Go to Related Record script step. Although this is a brief overview of the technique, you get the idea. For every record-locking scenario, there is usually an alternative approach.

[comment]

I do not recall where or what blog or forum post I have grabbed it from

http://my.advisor.com/doc/19364