I'm using a global field to filter a portal so that each user can set the global field and view different sets of records simultaniously. The problem I am having is that if any user clicks into any field, it is locking all records for all other users.

I came across these threads that I think are related to my problem:

http://fmforums.com/forum/topic/57413-relation-graph-cardinality-question/

http://forums.filemaker.com/posts/96fc4993b8

I think it may have something to do with having a global field on the RHS of the relationship. Has anyone else experienced this? Everything else is set up and working exactly how I would like, but the fact that all other users are locked out from editing all records is a big problem.

The global field is in the right-hand side of the relationship? That is, the global field is in a child record? That doesn't sound correct Joe.

Child records are not locked in a portal all at once, just the one that you're editing.

bcooney, could you please clarify? What doesn't sound right? Are you saying that what I have set up isn't right, or that what I am describing isn't possible in the first place and I'm describing it wrong?

I have the file open from two different computers and have repeatedly tested it. It is definitely locking all records for subsequent users once the first user enters any field.

The structure is set up so that there is a main table with the records, a table with the global for the date, and a 2nd T/O of the first table, all related by the date that the user sets as the global. The user changes the global date and records from the 1st table are filtered by a portal that shows records from the 2nd T/O.

MAIN TABLE---GLOBAL---2ND T/O OF MAIN TABLE

The portal shows the records from the 2nd T/O so each user can filter records based on whatever date they want to view.

You cannot have a global in the bottom half of a relationship.

Your description above is not clear to me.

What I think you're saying is that you have a self-join relationship, with a global date field related back to the same table MainTable::GlobalDate = MainTable::DateField. Correct?

Anytime I want to do this, I don't use the same table. Rather, I use a SYS table (a one record table) that allows a "bird's-eye view" into another table, to avoid any record lock.

I added a demo.

GlobalFilter.fp7.zip

Yes, the global does link to the same field on both sides of the relationship. Is that a bad practice in genreal? It is working for what I need, but the only issue is that all records are being locked.

Have a look at the demo. Global on top half always! Bottom half must be indexed. No globals or unstored calcs allowed.

By top and bottom half, are you referring to the left and right sides of the relationship? I'm running FMP v10 and when I edit a relationship the parent and child are displayed as left/right not top/bottom.

Also, if I have everything else working the way that I want despite having globals on the RHS, I really don't want to start moving everything around unless it's going to fix the record locking issue, which we haven't really discussed here. Will that fix it, or are you just saying that I shouldn't use globals on the RHS and that it's a separate issue from the record locking?

You cannot use globals in the RHS (bottom half, child table).

Just checked out the demo. I think part of the issue is that I have my global date in it's own table where as your demo has it in the same table, so you only use 2T/Os where I use 3. I'm still not clear what you mean by CAN NOT use globals in the RHS though. I AM using them in the RHS and everything works perfectly if there is only one user. I assume you mean you should not use globals on the right hand side and that is the reason the records are getting locked.

So should I move my global date field into the same table as the main records?

By the way, your demo only has one table, but in the same comment you posted the demo, you said to use two tables. Which method should I be using?

You can use one table, but what is the goal here? What is the "main" table? If you are trying to construct some sort of overview, I usually use a SYS table. And yes, your design may be the cause of your record lock issue.

Here's a revised demo using SYS to look down into the Invoice table.

GlobalFilter.fp7 2.zip

The main table consists of many records all having the same date. The goal is for each user to be able to filter the portal based on the date they want to view logs from. I'm working on a new set of relationships with the global in the same table as the rest of the records. I'm alomst done, then I'll check out your new demo. Thanks again.

"All having the same date." What does that mean, and what, then, are you filtering?

I'm still not clear what you mean by CAN NOT use globals in the RHS though. I AM using them in the RHS and everything works perfectly

The purpose of defining a relationship, I am sure you'll agree, is to make some records related and some not. A global field holds the same value for all records - therefore putting a global on the RHS of the relationship (i.e. the side that is supposed to supply the related set) does not serve the above (or any other) purpose.

In any case, modifying a global should not lock any records, so the problem is very likely elsewhere. Why don't you post a file showing the issue?

Here's a clone with just a few records so you can see how it works. Ignore the 2nd tab on the layout. It's just another view that filters based on a category and date range, rather than just the date.

This version is restructured so that all the relationships with globals have the globals on the LHS, and it is still locking all the files when accessed by more than one user.

TEST.zip

Credentials?

Credentials?

OOPS!

test/test

I even took the time to make a separate log in for you and still forgot to provide it :/

We need Full Access.

I just checked and the test account does have full access. The open script prompts a 2nd log in, just use the credentials test/test both times.

Were you able to log in? I still can't get more than one user to edit a field at a time. I'm thinking about just making a script that triggers on field access that commits the record and selects a non-field object to keep other users from locking it if they forget to click out of the field.

Why two logins? I did enter test/test each time.

Ok, try this one. I just checked again and it wasn't full access in the one I had zipped. Sorry about that. I've been trying so many different approaches to fix this that I've got multiple copies all over and mixed them up.

TEST-NHMFL Control Room Log Clone.fp7.zip

Because you're basing your layout on the same table that you are showing in the portal, then if that log record is in use by another user, then no one can create additional log records if they have that log record as their parent.

A dashboard like this should be based on a one record table that no one edits.

Also, it is not good practice to name fields with "." in their name.

Also, the global date field should be from the parent table, you have it as a related field (even though it's the same table).

Your "Globals" table does not contain any global fields.

Because you're basing your layout on the same table that you are showing in the portal, then if that log record is in use by another user, then no one can create additional log records if they have that log record as their parent.

A dashboard like this should be based on a one record table that no one edits.

So I should use a one record table with a date field to filter? But then all users will be forced to view the same date.

Also, it is not good practice to name fields with "." in their name.

easy enough to fix, thanks. I'll update that in a min.

Also, the global date field should be from the parent table, you have it as a related field (even though it's the same table).

That's what I had originally. Your first demo led me to trying put it in the same table.

Your "Globals" table does not contain any global fields.

It use to. That's where the globals were before I moved them based on your first demo.

By the way, the two log ins was because some of the shared computers around here were logging in automatically because a previous user had added the password to their keychain. Then they would be stuck using someone else's account. It was easier than constantly removing passwords from keychains every time someone clicked the "remember my password" box on log in.

So how would you structure the relationships to keep the exact same functionallity but allow for multiple users? Should I make a duplicate T/O of the table the layout is based on, then change the layout to be based on that? I don't understand how the one record table would work in this case because it seems like that would remove the ability for multiple users to view different dates. If the date was filtered by the value of a field in a one record table then they would all have to view whatever that one date is, right?

Just checked out the demo. I think part of the issue is that I have my global date in it's own table

If the global filter field is in it's own table, and you are using a layout based on that table ( Like a globals table ) presumably there is only one record in the globals table. when your users go to that layout to view the portal they are working from the same source record. This will cause your record locking. I use a similar technique where I have a layout based on a Globals table showing a portal to the table I wish to show data from. I had to add a way for the user to advance to another record in the Globals table if the record locking happens.

If the global filter field is in it's own table, and you are using a layout based on that table ( Like a globals table ) when your users go to that layout to view the portal, presumably there is only one record and all the users are working from the same source record. This will cause your record locking. I use a similar technique where I have a Global table with my filter fields related to the table I wish to draw from. I had to add a way for the user to advance to another record if the record locking happens.

So you're saying I should use the same techique I am, but have a script advance to a different record if access is locked?

[edit] I think I have an idea! If all records are viewed/edited via portal then it doesn't matter what record a user is viewing. I could have the open script select a different record for each user. There's only about 8 accounts.

If (getaccountname) = user1

go to record #

etc...

Barbara,

You seem to come up with more rules and good practices than I can keep up with...

A dashboard like this should be based on a one record table that no one edits.

Perhaps we are not looking at the same file. The one I see has a portal that allows record creation and editing. If the parent is a one-record table, you will indeed lock the entire thing as soon as one user starts modifying any portal record.

it is not good practice to name fields with "." in their name.

Why?

I didn't script it myself, because I had no time to work with when the problem came up. I just added a record advance button to the layout. But, yes, if you can script to capture for record lock and advance to the next record I would think that would get you by.

In the future, I intend to build portal views such as this starting from a layout based on my Employees table. Whenever a user goes to that layout I will script it to bring them to thier own employee record. That way every user accessing this layout will be on a different record to begin with.

By the way, i think I was a step behind on this one. I replied from the end of page 1 before I realised there was another page. Ooops :)

IMHO, a Users or a Sessions table needs to be the parent here.

Thanks to everyone who helped on this one. I see the need for a users table comment. I'll implement one eventually. I'm just using a script to jump to a different record for each user for now.

If the parent is a one-record table, you will indeed lock the entire thing as soon as one user starts modifying any portal record.

Even if the parent is a record from a one record table, and no parent fields are available for edit (and the only field available from the parent is a global field)? Sorry, I should have tested (I never edit portals directly...and it shows.)

Yes, I'm full of rules. "." aren't sql-friendly...and I care about that.

+1 vote for User or Sessions table, then.

I have the same problem.

I have a dashboard based on a one record table that no one edits. (SYS table)

This table have a global gDateFilter that is used to link with a portal record (INVOICES Table).

SYS table ----- connect to ------ INVOICES table

I have a field SYS than have a portal with INVOCES records.

The problems is that two diferent people dont can modify distint records in the portal using this relation.

Any solution?

You can see an example in this link:

https://app.easyforyouproduction.com/fmi/webd/GlobalFilter99

 

Thanks

 

 

 

Hi cesteban and welcome to the FM Forums,

Please post your attachments here so we don't have to leave the Forums to view or access them.

TIA

Lee

p.s. It is always better to create a new Topic rather than use one that is older than the current FileMaker Pro Version.

Okok,
I only link to the webdirect solutions because is more easy to check this issue with several users.
Do you want that I create a new topic?

Thanks again.

Do it if you want, but here is the problem with linking your files elsewhere.

 

I sent you a Private Message earlier, and I see you haven't read it yet. Please read it now, as it has some helpful information about how to post your questions.