Hi @NatalieAtSafe,
I am using FME(R) 2016.0.1.0 (20160130 - Build 16174 - WIN64) desktop. In child workspace, i have changed the publish parameter type to 'Text (Multiline)'. In parent workspace, when i am passing two numbers comma separated in workspace runner, Comma automatically gets replaced by '<comma>'. Eg. I am passing '123,345' but it is passing '123<comma>345' to child transformer.
Hi @subrat, it's intentional that a comma will be encoded to <comma> in the Text (Multiline) type parameter value when it is passed to FME engine through a command line which is generated by the WorkspaceRunner. e.g.
"C:\Program Files\FME\fme.exe" "C:\tmp\child.fmw" --PARAM "123<comma>345"Then, in general, every <comma> within the parameter value will be decoded to the comma (,) automatically when the value is passed to a parameter of a transformer in the child workspace.
Where did you observe the not-decoded <comma>?
Hi @Takashi,
In my child workspace, i am using this publish parameter in Oracle Non-spatial reader's where clause. These values passed are supposed to be used as IN query in that reader. Like "ID in (123,345)".But now it is passed as "ID in (123<comma>345)" and oracle reader fails for syntax error.
Hope this helps.
Thanks for the clarification. I've understood your situation, but was not able to reproduce the issue.
I created a Text (Multiline) type published parameter called "PARAM" and referred it from the WHERE CLAUSE parameter in the Oracle Non-spatial reader feature type, like this.
Then, the child workspace was able to run successfully with setting comma separated values (e.g. "1,2,3") to the parameter, through a WorkspaceRunner in another workspace.
I tested this with FME 2016.1.3.2 build 16717. I think the only difference from yours is FME version.
Thanks @takashi. I was updating the where clause in reader's parameter section under Navigator and it was not working. When i updated same in Feature Type Properties as you showed, it worked. I think this is a product bug. Thanks for pointing out the issue.
Thanks @takashi. I was updating the where clause in reader's parameter section under Navigator and it was not working. When i updated same in Feature Type Properties as you showed, it worked. I think this is a product bug. Thanks for pointing out the issue.
That was the difference!
- WHERE Clause (Reader Parameter):
"An SQL WHERE clause can be applied to the selected tables, to constrain the the row selection in tables chosen in the table list (for example, NUMLANES=2)."- WHERE Clause (Reader Feature Type Format Parameter):
"This parameter specifies the SQL WHERE clause applied to the attributes of the layer’s features to limit the set of features returned. If this is not specified, the value of the WHERE Clause reader parameter is used. If nothing is specified, all rows in the table will be read and returned as individual features."
Hi @takashi, then why reader parameter where clause is not working? If i have 100 feature types in that reader with common where clause, then also should I mention where clause in each feature type? Or we have any option for global where clause?
Hi @takashi, then why reader parameter where clause is not working? If i have 100 feature types in that reader with common where clause, then also should I mention where clause in each feature type? Or we have any option for global where clause?
In the interim, the only workaround I can think of is to define a Scripted (Python or Tcl) type private parameter to decode the encoded published parameter value and refer it from the reader WHERE Clause parameter. Assuming that a Text (Multiline) type published parameter called 'PARAM' is defined:
Scripted (Python) Parameter Example
import fmeobjects
s = fmeobjects.FMESession()
return s.decodeFromFMEParsableText(FME_MacroValuest'PARAM'])
return MFME_DecodeText $FME_MacroValues(PARAM)]Hi @subrat and @takashi,
I have filed a PR on your behalf to look into and address this issue. My apologies for any inconvenience this may have caused.