Portal record locking

[ddreese]

I have a layout that has two portals. Both portal relationships are self-joins to the table that the records reside in. None of the fields are editable on the layout, and when one person is already on that layout it is locked and no one else can even scroll through the portals.

Any ideas other than placing the portals on a layout not in that table (i.e. no self-joins)? The only goal I have is to be able to have everyone be able to scroll the portal rows no matter if 1 person or 40 people are in that file.

[Vaughan]

This is a known problem: the first row (related record) of the portal is locked.

About the only suggestion is have is to put each user on a different record; or use a list view layout and get rid of the portal and self-join completely.

[ddreese]

Thanks Vaughan, how can I dynamically check to see if the record is locked and then move the user on to another record? The easy way would obviously be list mode, but I have two lists that are somewhat different information so I'd have to do two lists. Hmmm, I guess I'll pose this question to the higher powers (bosses) and see what they say.

Thanks again

[Ugo DI LUCA]

Hi,

I succesfully followed Vaughan's suggestion in a small application I had, and later switched to fixed portals, scripting the scrolbar bar.

HTH

[Fenton]

You can check that a record is locked by using:

Set Error Capture ["On"]

Go To Field ["A field in the portal"]

If [ Status(CurrentError) <> 0

Record is locked

End If

There is a specific error code, but anything other than zero is not good.

The problem is what to do in that case. The thing about portals is that they are more or less "portable." Whatever key you have on the left can be set into a global field. Then it no longer matters what record you are actually "on." So one method is to just Loop through records until you come to one that is not locked.

Another method, if you know who the people are, is to go to THEIR record, in a Login or User file, where each person has 1 record. Set the left side global there, with a relationship back to the line items file with the data.

Fortunately this is less of a problem in version 7, as just parking the cursor doesn't lock the record, neither does entering globals. The expert is Ilyse Kazar. There was an article by her at FileMaker Advisor a while back.

Here is a post by Jason L. DeLooze, another expert, with a radical solution:

My philosphy with multi-user databases is to keep the users out of the records as much as possible. For example, when a user needs to edit a record, copy the data into globals and "let them idle" all day (if need be) "editing" the record, but not locking the record. "But how?" you ask, since copying the field data into globals doesn't prevent record locking when the user clicks into one of those globals. But what if you remove the record - no, don't delete it - but remove it from the FOUND SET? That's right - simply do a "Find All" & "Find Omitted" script steps, and the user is idling in the globals with NO underlying record to be locked! Clicking in any of the globals doesn't lock any record, since there is no "current record".

This technique can be used elsewhere - with your QuickSearch - and those "related" records won't be locked either (the user clicking in the portal just gets them that pesky "No records are present ..." Alert, but I'm certain a well-placed set of buttons will keep that annoyance from your users.)

And here is a synopsis by Anne Verrinder (Ilyse's partner at http://www.datatude.net)

Set Error Capture [On]

Loop

Go To Field (Whatever) <-- or Set Field if Whatever is not on layout

Step will fail if record is locked by someone else

Set Field [g.error, Status(CurrentError)]

If g.error = 301

Go To Record [Next]

End If

Exit Loop If [g.error <> 301]

End Loop

In a data file, if the layout only has globals and portals, doesn't matter which record you're one, but this procedure avoids everyone always starting out on first record and colliding.

>Is there a better way to do this?

If you have a Users.fp5 file, put all your selection portals in there and make sure everyone lands on their own record.

Others have suggested that you get yourself in a zero found set (no records to lock; globals and portals still work). Downside: portal buttons don't work -- no parent record from which to Go To Related Record.

Since you're using 5.5, you can use record-level access to overcome portal scroll lock. Users without Edit privileges cannot lock records, under any circumstances, so if you put a flag field in your one-record file, you can set up passwords for your users that allow Edit, BUT only if that flag field = 0. When you take them to the portal-selection layout, set the flag field to 1 -- they won't be able to lock anything up. In any buttons on the layout that take them off that layout, set that flag field back to 0. It works, I've tested it. This only has to be done in the parent file.

[-Queue-]

If you take the Show All Records, Show Omitted approach, be sure to check afterward that there are no records found that might have been created by other users during the time it took to perform those two steps.

Show All Records

Show Omitted

Loop

Exit Loop If [not Status(CurrentFoundCount)]

Omit Record

End Loop

[ddreese]

Well I think I have it about 70%, but I'm still having problems.

If I open up the status bar on the side, I can see that I'm switched to a different record but the portal still remains locked. My script:

Allow user abort[off]

set error capture[on]

show all records

goto record/request [first]

loop

go to field "transaction type" <------ This field is in the portal, using the relationship

Exit loop if status(currenterror() = "0")

goto record/request[next]

end loop

goto layout [xxxxx]

Like I said, I get taken to an different record completely on each machine, but the portal is still locked. I'm sure it's probably something stupid that I'm doing wrong.

[Ugo DI LUCA]

Hi,

What is exactly your relationship ? A self-Join ?

[ddreese]

Yes, as I mentioned in the initial post, I have two portals that are both self-joins to the file.

[Ugo DI LUCA]

Hi,

Is the next record you're moving to currently part of the portal records ?