marking a record with an id unique to a session

[jjjjp]

I'm wondering whether there is a system-generated id that one can be sure will be unique to a session. Searching the get functions doesn't seem to yield anything useable.

I have a schedule of workshops, and I want to be able to send out emails to prospective presenters offering them only a selection of all of the offerings for a given year. So I'm thinking I'll mark all of the workshop records for that year using the unique id, display those records in a portal, and then further mark the sessions to keep track of the ones the user selects by clicking a button that runs across the whole row. A script will generate appropriate email text offering just the selected workshops. It will then unmark the workshops.

This is a multi-user environment. I assume the right way to go about this is to mark records. Using the account or user name doesn't seem like a good idea because, however unlikely, there might be more than one session going on initiated by the same user.

I could of course generate this unique id myself (create a field in my system parameters table that gets incremented at the start of each session and immediately gets copied to a global field?). But if there is something ready at hand, that would be much better. (Or maybe I am not approaching this in the best way to begin with.)

One more question about doing this kind of operation: Is it better practice to work with a temporary set of duplicates of the records? As I see it now, the advantage of duplicates would be that one wouldn't have to worry about a record being blocked halfway through the process (at which point, I guess, one would either have to abort or give the user the option of trying again). The disadvantage is that one would have to filter out the marked records in all portals displaying the records in question (workshops in this example). But there may be other considerations I haven't anticipated.

Edited September 14, 2010 by Guest

[bcooney]

This multi-user friendly method of marking records may help: http://fmforums.com/forum/showpost.php?post/293833/

[jjjjp]

Thank you for pointing me to what looks like an ingenious solution.

I think I see one small problem with the way it is set up that can probably be easily remedied. Look at the expanded table (attached), and see what happens when you click on the checkbox of the record with id = 13. Three records get flagged. This can no doubt be easily remedied by changing the definition of flag_marked to include paragraph markers in the calculation. But the global variable gMarked might need to begin with a paragraph marker.

I'm not familiar with what happens when you relate two tables in a relationship graph by equality and one side has a single value where the other side has a value list. Does Filemaker consider the two records as related when the value on the left side exists in the value list on the right? I'm wondering specifically how the GTRR works in the script Find Marked. If one wanted to do the same thing with Finds rather than with GTRR, would one have to include a loop in the script that, starting from an empty set, ran through the whole list of values in gMarked and expanded the found set with each value?

MarkRecordsDemoProblem.fp7.zip

[bcooney]

Yes, you need to wrap the calc with carriage returns. Thanks for catching that.

In FM, if left or right has a list, then it is an OR match. However, you cannot have an unstored calc on the right (child) side of a relationship. In fact, I'm struggling to remember if I've ever had a multikey on the right side...

The Find way would require a loop, creating a new request for each search criteria.

[jjjjp]

Thank you. You have taught me some valuable things I never knew. E.g., I came to the erroneous conclusion a while ago that Filemaker somehow couldn't handle unstored calculations in a relationship (despite what the online help indicated) and was frustrated by the apparent limitation. (Filtered portals, however, have helped me out in a few jams.) I will be more careful about how I lay things out on the graph: where possible, parents on the left.

[bcooney]

You are certainly picking this up quickly.

To be clear: unstored on left (parent) is OK.

Parents on left. That's why I prefer anchor-buoy. I can't think backwards, lol.