Steve Martino

You may want to back up and tell us what the file is suppose to do. What you have is not set up at all correctly. Seems like it's a sandbox for trying out something.

Most developers probably wouldn't be interested in modifying a starter solution. Starter Solutions are basically created to show users the kinds of things FileMaker could do, not necessarily the best way to do them. Plus if you're deploying this on server, there are many security issues to consider. Might take just as much time to figure out and modify a starter solution than just building a custom or semi-custom db.

Can you show the script you are using?

Is that 5 radio buttons with I button each or is that 1 radio button with 5 buttons?

Well the relationship method would be the easiest. What are the complications? You could make a looping script that would take your list of ID's with entering find mode, set field, new record request, set field, etc. until you entered all the fields then perform find. I don't know if you can only make so many find requests.

There are quite a number of sample files out there that include 'Picker Lists'. Some use a conditional or dwindling value lists, and others use a picker list tied to a relationship that excluded people already picked. If I'm not mistaken, I think the FileMaker Training Series has a chapter and sample file to do this exact thing. When I have time a little later, I'll see if I can find it.

I would use a card layout with global fields for the find. You can also have fields with checkboxes for exact, wide, cancel and any other parameters. Then a 'Find' button would gather all the criteria and logic and perform the find. Values stored in a child table can also be put into a value list.

If you had a relationship or portal sorted by invoice date, 1 one row portal would only show the first invoice for each customer.

Ahh I see it now (after testing). Thanks. Looks like the challenge was too (hard for us) easy to resist!

Look who came out of retirement!!! Welcome back Comment!!! Long time no post . Question for you you, if you don't mind. Why do you need the SerialIncrement function at all? It seems like : gives the same result. Just wondering if I'm missing something. Thanks Steve

Little concerned about your structure, see if this helps. FirstAttemptMOD sm.fmp12

Make sure as you import each record gets a time stamp, or at least a date stamp. You could easily search/report price history broken down by date in a sub-summary report.

That i have created , when i go into the units form layout i could see the unit and its details and then a 1 line portal that show the active tenant at default and via a value list that runs a script one could view older tenants . Not according to you diagram, but if @Ocean West's sample file has you on the right track, then go with that. You're 1 line portal could have a scroll bar that will show all past tenants when you scroll, leaving the active tenant on top.

I think maybe you need another join table Units_Tenant which would show all rental history on that unit. Similar to a Line Items table in an invoicing solution. Then a portal on Units sorted by checkbox (for current tenant) would be at the top. You can also put in a script trigger on the checkbox so only one can be checked in a portal.

Or MasterTable::primary key field = DetailTable::primary key field, using your Table/primary key fields.