I'm a little confused as to how you are trying to use the $(levelv) parameter and the levelid attribute, and why you are attempting to alter the parameter repeatedly.
I'm a little confused as to how you are trying to use the $(levelv) parameter and the levelid attribute, and why you are attempting to alter the parameter repeatedly.
Thanks for the support, I would like a setup that on every loop the levelid goes decreases by 1, this levelid is used in the reader in the where condition to filter the data being read. I am therefore trying to use a user parameter to hold the new value to filter by.
Thanks for the support, I would like a setup that on every loop the levelid goes decreases by 1, this levelid is used in the reader in the where condition to filter the data being read. I am therefore trying to use a user parameter to hold the new value to filter by.
A user parameter is something like a constant, cannot be used as a variable like that. You will have to use a feature attribute to test the condition for finishing the loop.
After you Input port, replace the AttributeCreator and ExpressionEvaluator with a parameterFetcher, to get the levelv parameter as an attribute (levelid).
The FeatureRead where clause can be build from the levelid attribute LEVEL=@Value(levelid).
The initiator feature can then have an expression levelid = @Value(levelid)-1
And the tester should test the attribute and not the parameter.
You don't need the second attributeCreator at all.
After you Input port, replace the AttributeCreator and ExpressionEvaluator with a parameterFetcher, to get the levelv parameter as an attribute (levelid).
The FeatureRead where clause can be build from the levelid attribute LEVEL=@Value(levelid).
The initiator feature can then have an expression levelid = @Value(levelid)-1
And the tester should test the attribute and not the parameter.
You don't need the second attributeCreator at all.
Hi @jdh, does your comment agree which what @Takashi is saying about user parameters being constants? Thank you
Hi @jdh, does your comment agree which what @Takashi is saying about user parameters being constants? Thank you
Yes.
You get the value once and store it as an attribute (ParameterFetcher) which you can then manipulate and change the value of during pthe process.
Yes.
You get the value once and store it as an attribute (ParameterFetcher) which you can then manipulate and change the value of during pthe process.
workbench.zip
Thank you for the help, this looping is making me loopy at the moment. I have simplified the workbench but I get the report in the log:
Microsoft SQL Server Spatial Reader: Query failed, possibly due to a malformed statement. Query Text `SELECT * FROM *_dsg_source] WHERE LEVEL = _startinglevel'. Provider error `(-2147217900) Invalid column name '_startinglevel'.'A fatal error has occurred. Check the logfile above for details
I dont know why it is looking for the _startinglevel when in the feature reader I set it to look for LEVEL = @Value(levelid)
thank you for the loopreader example, I don't understand why when I tried to setup the loop it wanted me to set it up as an external fmx, however the basic amended version from yours works well. thank you so much.
thank you for the loopreader example, I don't understand why when I tried to setup the loop it wanted me to set it up as an external fmx, however the basic amended version from yours works well. thank you so much.
For technical reasons, FME can't handle blocking transformers in a loop in an embedded custom transformer, and requires it to be linked.
When creating the loop, if it thinks you're putting in a blocking transformer, it will tell you to turn it into a linked transformer. It tends to err on the side of caution, and will flag some loops that are not actually blocking. If you know for certain that it's not blocking you can ignore the message and keep it as embedded (which is what I did).
Be aware that if it is a blocking loop and you keep it as embedded, FME will throw a fatal error.