I noticed something while trying out the Invoice Starter Solution.

It goes like this:

In the DB the ContactID for the invoice table is auto calculate variable $$contactid which is set by a script prior to opening the layout to which the table is referenced.

When the DB and the Interface is in the same file... i dont see a problem as in the example.

However when i split up the db and the interface, i.e. the db is its own FM file, and the interface its own... then i think it does not work. I cannot pass the variable over to the db file.

Is this true? That you cannot pass variables to the DB if the db is on a different file? What i did was explicitly do a SetField(ContactID) and that worked.

Thoughts anyone?

You are correct…variables don't pass to other files. You found one way around it using Set Field. You could also create a Table Occurrence of the external data file in your interface file, then I think that works. You could also use GLOBAL fields, or perhaps even Script parameters to pass the variable?

I'm sure someone more knowledgable will pipe in with a reality check.

- - Scott

About using Table Occurences... Nope.. it doesnt work. I tried that before.. The only way i could think of is setField. I was wondering if there is any side effect to it.

Global variables are file-specific. Global fields are not. You can also include your variables in a script parameter, and set up a utility script in the target file that handles creating the variables there.

is there an example of such a script that handles passing variables from a file to another? Thanks!!

In pseudo code:

Perform Script [ otherdatabase ; scriptname ; scriptparameter ]

The "script in the other database uses Get( ScriptParameter ) to get the value from the script.

It's also possible to pass multiple variables in a script parameter, and there are a couple of common methods. My preference is to use name/value pairs, e.g.

"id = " & invoiceID & "; discount = yes" // etc.

The target script then parses this out using a custom function. Some people take it a step further and use a custom function to create the parameter as well as parse it, but I haven't found a compelling reason to do that.

Another way to go is simply pass the parameters as a list, e.g.

List( invoiceID ; "yes" )

The target script would then parse this using GetValue( Get( ScriptParameter ) ; 1 ) etc.

At least one well-respected developer argues for the latter method.

i think i need to read up on variables.....