bruceR

While comment's suggestion works, I experience a few problems with it. Consequently, I always add a calculation field to my tables, and make it unstored, get( recordNumber). See attached example file and screenshots. The advantage of using a layout variable is that you don't need to modify the field definitions. The disadvantage, in my experience, is that any time you touch the formatting of the variable, it resizes itself. SimpleRecNum.fmp12

Glad you have found it useful. It's a good staring point for you but there are certainly things I'd change or improve. Others may or may not jump in to demonstrate some of those improvements, by modifying this file or contributing their own.

I updated the example to take away a few of the messy parts.

Comment has suggested a much more relational approach. Attached is one take on that, hopefully it will give you some ideas. It uses tables for Patients; CASES; CaseCharges (line items); FEES; and a PROCEDURES table and associated ProcedureCharges table. It is in a semi-polished state, some things are in place that I was just testing. CHARGES_TEST modBFR.fmp12

As stated by comment; you don't select it using the TYPE field. CardsMyExample MODB.fmp12

" I have 2 tables; CARDS and TYPE" Nope. You have two tables; PASSWORDS and TYPE. Nothing about your design requires TYPE to be unique.

Help will be impossible until you specify user name and password for your TEST file.

Why? Why do you think you need to do this?

It’s generally a lot easier to understand a complicated request if you post a clone or an example file.

What you have quoted is erroneous. There can be no double quote in the go to field statement. But delete that line anyway; it isn't needed. Instead: Go to Layout ["Client Data" (Client Data) Replace Field Contents [ No dialog ; Client Data::New Emergency Date ; ""]

Note that this exact same subject is being discussed on FileMaker Community. https://community.filemaker.com/thread/184913

I'd suspect something else then. Some conditional formatting or hide calc, some ill-written custom function, even your data viewer watch functions; something is declaring that variable. The fact that you can't post a full and complete script - is also troubling. Have you got Advanced? Can you generate a DDR?

Where is your actual script? How are you triggering the script? Can you show us your file or a simple example file? There will need to be a second step in the script so you can stop in debugger and look at the variable contents before the script ends. Since you are using a script variable ( single $ variable) it will always be empty after the script runs. While this is something you should be able to do successfully - in real life, what do you want to do with $fieldName?

WHICH two layouts? No, they are not independent of each other. They are based on the same table. Your entire premise here has been to do something "not the parent" which makes no sense, and you have been unable to explain.

What does select mean - to you? And after "selecting" - what is next? What are you actually trying to do?

Doug, there is a very important omission in your script. After the first Perform Find, you need to re-enter Find Mode. Otherwise; you're changing data in the current record. And you probably want to add some error trapping. Also: not sure what's up with your square brackets in the set field statements. I removed them here. Enter Find Mode [] Set Field [template::year ; 2018] Set Field [template::InParentDiary; 1] Set Error Capture [ On ] Perform Find [] If [ get( lastError) = 0 ] Enter Find Mode [] Set Field [template::season ; "spring"] New Record/Request Set Field [template::season ; "summer"] Constrain Found Set [] End If

Basically you are declaring: you tried something and it didn't work. What exactly does your script look like? Since you have return-separated values (from a checkbox field) you are going to have to create multi-step script.

May I suggest that you work with this version going forward. It clarifies key field names, reorganizes the graph, and eliminates "portal" from any table or relationship names. The TO may be used in a portal. But labeling the TO as someThing_someThingPortal hides actual relational concepts. Test File DemoJOBR.fmp12

Here's cleaned up graph screenshot though.

That isn't the way it looks to me. Looking at your description and your file is like looking at what used to be a functioning car. Now the spare tire is in the back seat; the steering wheel is attached to the left fender; and the windshield wiper are attached to the passenger door handle. No, I don't understand your vision of where you're going with your file. No, I don't think the solution is simple.

It's a mess. The "Library" and "Album" and "Song" tables are the same table. You don't have a separate Song table. The Song Title is set to always auto-enter "" into itself. There are established solutions which do this.

Your request makes no sense. You cannot print in layout mode. For that matter; you cannot click a button in layout mode; and you cannot enter data into a field; global or otherwise; in layout mode. It is extremely difficult to understand what you are trying to do. If you can attach your file; or a clone of your file; it would help.

Then I don’t understand what you are trying to do. If you are in browse mode; and the found set is not zero; then the script should always run? What initiates the script? User clicks button?

You have not defined what it means for a record to be “selected “. Neither we nor Scriptmaker know what you want. How is a “selected” record different from the current record?

Here it is again (hopefully). Reason for CREATE relationship: The existing relationship leave a non-functioning ghost bottom row in the portal. WTC_v_1_2017-18_TEST_ModBFR.fmp12.zip