The problem with flagging records this way (aside from the conflict you already noticed) is that you also change the "last modified timestamp" for any record that gets flagged, when a true record modification really didn't take place.
A good way to "flag" and recall records is to do it virtually in memory.
Say for instance, a simple flag button with a single script step:
Set Variable [ $$Flagged ; List ( $$Flagged ; YourTable::YourPrimaryKey ) ]
and a slightly more complex, but still fairly quick recall script:
Enter Find Mode [ no pause ]
Set Variable [ $count ; ValueCount($$Flagged) ]
if [ $count = 0 ]
Enter Browse Mode
Set Variable [ $i ; $i + 1 ]
Set Field [ YourTable::YourPrimaryKey ; "==" & GetValue( $$Flagged ; $i ) ]
Exit Loop If [ $i = $count ]
If you need to make it even more complex, where it saves the flagged results even if the user quits filemaker, you can replace the $$Flagged variable with a record in a simple table that corresponds to the user by Get(AccountName).
Can you designate fields to be user specific?
You can make them global – a global field is user-session specific – but that won't help you (directly) in marking records.
One way to solve this: use a global $$variable to add to and remove from the IDs of a selected record.
As a record selection flag, you could simply add an appropriate layout object (say, a graphic) and use Hide If with
IsEmpty ( FilterValues ( $$selectedIDs ; Table::ID ) )
To turn this selection list list into a found set, create a global text field, and a self-join relationship where
Table::gSelectedIDs = Table_self::ID
To find selected users, use this script:
If [ IsEmpty ( $$selectedIDs ) ]
Set Field [ Table::gSelectedIDs ; $$selectedIDs ]
Go to Related Records [ Table_self ; current layout ; matching only )
You could also write a looping Find script, for which you'd need neither global field nor relationship.
"You could also write a looping Find script, for which you'd need neither global field nor relationship."
Seems like that's the suggestion path I was on!
I like the looping find idea, but if your flags need to have any kind of permanence or resiliency, then this won't work.
Here's another way that would be multi-user safe and not cause modified stamps to update.
Create a global field for your persistent ID in the parent table
Create a table with at least these field: ID_parent, persistent_ID, flag
Now you just need a one to one relationship with the parent record that also uses the persistent ID (or user id) in a global on the left side. That way they are user specific, and also relate directly to the record they need to flag.
To clear the flag, you can either set the "flag" field on the related record or just GTRR and delete those.
Mike Beargie wrote:
Seems like that's the suggestion path I was on!
We were both in Editing limbo while the other was writing his response.
btw, you can use Get ( RequestCount ) to calculate the exit condition.
thanks chaps. I'm working with Mike's initial post above but when i try the find script i get a "no records match this criteria" dialog.
The primary keys are definetely being listed correctly as I've added the $$flagged variable to the layout to see it in action. Have I got the find script correct? What is the purpose of the new record set? Also I don't completely follow the $i bits? or why the = is in commas making it lose its function?
ah sorry had a step slightly off it does work now.. however I'm curious what the new record/request step is for?
$i is a counter, it's just counting the number of times you're going through the loop. This is so it can exit when it has made find requests for each value in your $$Flagged list.
The "==" is the operator for exact match for a field. If you do not use it, your find can result in false positives as filemaker will include "825" and "8250", "8251" "8253", etc... in the find results because they all contain 825.
You are making a new find request each time through the loop (after the first record, which already has one from entering find mode), because you are doing OR searches. AND searches are done in the same find request.
EG: find records where ID = 825 OR ID = 826 OR ID=827. Versus: find records where ID > 800 AND someOtherField = SomeOtherValue...
Do you have script debugger to step through the script as it runs to make sure it's creating the proper find request?
Additionally, you may want to implement a custom function like this:
In order to remove a primary key from your flag.
Don't use Substitute() to try and remove the value out of $$Flagged for the same reason why you need "==" for the find.
Thanks Mlike, that all works a dream.
Your Go to record [First] is inside the Loop. You need to put it before the Loop step.
man alive. sorry long day. thanks