ExecuteSQL, How to . .

It all depends on context. To access data in a single record table you do need to connect the table so that the data is visible in the correct context.

To avoid context issues you can do a bit more work upfront. Create a globals table. That is a table that is full of global fields named after the data fields that you have in your single record table. At startup (usually) you have a script visit the single record table and pass the data from all of the fields into the fields in the global table. When the data is in a global field it can be seen from any table in your system without need any relationship at all.

I liked this idea. I created a table in ONE of the 22, MA_Pref.Local with four global fields.

I created a script to:

image

When I run the script I get that the Local fields are not modifiable.
I have an X-Relationship between the two Tables:

When you have the opportunity, I would appreciate any feedback.

You are meant to set the global field to the value of the settings stored in the normal data fields.

MA_Pref.Local is global fields... I am trying to set the values when opening the file, in this case APInvoice.FMP12. Setting the GLOBALS to the values in the MA_Pref table.

I would think the script I posted would do it. But I do not know why the GLOBALS in MA_Pref.local are not modifiable.

Playing around, trying different processes. I deleted MA_Pref.Local.

I used IMPORT RECORDS to create a new MA_Pref. I changed the FieldName.X to GLOBAL.

Instead of using SET FIELD to initial the values, I used an Import Record script step. Each time the files are opened, that will run.

@Malcolm Thank you very much for the patience and assistance. Now I need to do my "job" of accounting. Have a great weekend.

Possibility: There must be at least one record in the MA_Pref.local table if you are attempting to set the global field value via a relationship.

image

The screenshot of script steps (above) does not align with the quote above. The script steps were set up with the non-local fields as the target field to be set. In other words, it is the reverse of what is actually desired.

As an example:

Line 4 attempts to set the field: MA_Pref::Finance_Server.x

With the value of: MA_Pref.Local::Finance_Server.x

If MA_Pref.Local is the table occurrence with the global fields, then it should be the other way around.

@steve_ssh I did get very confused. The MA_Pref file has the one table with one record. Four Fields holding paths.

In the recipient files. I created MA_Prep with global fields, with one record.

My solution changed from a script that uses SET FIELD to set the paths in the four fields, to Importing the record from MA_Pref to the MA_Pref.Local in each field. Twice (that I have added it to a file) that has worked.

Modifying the scripts in the recipient files has not worked. I work with setting variables to import using the GLOBAL fields for the path and adding the file name. Has not worked.

To get my work done, I am having to hard code the new paths.

I do appreciate the assist. This is my most challenging project.

It sounds like the hard-coding will get you by for the time being.

As far as coming back to it some other time, it seems to me like you are fairly close in that you have a handful of good ideas to work with. I think that what will get you to success will be just a little bit of study to come up to speed with a few FM topics, or perhaps an increased focus on the details involved.