"a= "& Quote ( "Insurance") & ";b= " & Quote ( "T24a_Insurance_Patients||Id_Patient|")
"a= \"Insurance\";b= \"T24a_Insurance_Patients||Id_Patient|\""
but the literal text: T24a_Insurance_Patients||Id_Patient doesn't look like a valid file path, so maybe that shouldn't be quoted.
You might also consider this let expression:
Set Variable [ $Dummy ; Value: "Let ( [ $$Filetype = \"Insurance\" ; $$Path = \"T24a_Insurance_Patients||Id_Patient|\"]; 1 )" ]
As a way to set values to these two variables in one step. Of course it would actually look like:
Set Variable [ $Dummy ; Value: Evaluate ( Get ( ScriptParameter ) ) ]
And if your list of values to pass as a parameter are never null (or only one can ever be null), you can use this simpler method:
Script Parameter: List ( "Insurance" ; "T24a_Insurance_Patients||Id_Patient|")
Set Variable [ $$Filetype ; value: GetValue ( Get(ScriptParameter) ; 1 ))
Set Variable [ $$Path ; value: GetValue ( Get(ScriptParameter) ; 2 ))
Option 1 worked. The path is valid - it's how I know how tables are linked. Thanks
I will note one bit of caution here with your indirect data references: When you put file names, Layout names, table occurrence names or field names into an expression as quoted text like this, your solution becomes a bit "brittle" (easily broken). If you later rename the object so referenced--which is easy to do and will not throw up any error or warning messages, your expression now fails to evaluate correctly and thus "breaks".
I thus try to avoid a literal string for such objects if there is any alternative.
I can, for example, pass a field reference as a script parameter with this expression: GetFieldName ( TableOccurrence::FieldName ) and then renaming the table, table occurrence or field will not cause the wrong text to be used to refer to that field.
Get ( LayoutTableName ) can also be a useful way to get to a table occurrence name without needing quoted text to do it.