Skip to main content
Solved

Help resolving error with FME script not running on different environment

jstanger
Forum|alt.badge.img+1

This may be due to my inexperience but I have an FME script I have been modifying for a client, no new nodes added, and it throws up an error when the client tries to run it. The script runs with no issue on my own dev environment but when the client runs it using their environment it seems to fail. The error log message is rather confusing to me so I hoped someone here might be able to help point me in the right direction. Unfortunately, I can't access the client's environment so I'm stuck with remote debugging.

The error in question that stops the script is as follows:

2016-09-12 14:55:16| 1.5| 0.0|ERROR |Labeller_TDUCT_start(LabelFactory): The clause 'MINIMUM_LENGTH 0 REJECT_INVALID_GEOM YES' within 'FACTORY_DEF * LabelFactory FACTORY_NAME Labeller_TDUCT_start INPUT FEATURE_TYPE AttributeRounder_OUTPUT PLACEMENT UPPER_RIGHT LABEL_ENDS yes PLACEMENT_DISTANCE 0.0000001 PLACEMENT_SPACING 0 MINIMUM_LENGTH 0 REJECT_INVALID_GEOM YES OUTPUT POINT FEATURE_TYPE Labeller_TDUCT_start_LABEL @GeometryType(fme_text,@EvaluateExpression(FDIV,STRING_ENCODED,<at>Value<openparen>length<closeparen>,Labeller_TDUCT_start),0.000015,@Value(LabelRotation),ENCODED) @RenameAttributes(_label_rotation,LabelRotation) @RenameAttributes(_parallel_rotation,ParallelRotation)' is incorrect. The parameter to MINIMUM_LENGTH must be a constant value, a value-of (&) attribute, or an FME function call 2016-09-12 14:55:16| 1.5| 0.0|ERROR |The clause 'MINIMUM_LENGTH 0 REJECT_INVALID_GEOM YES' within 'FACTORY_DEF * LabelFactory FACTORY_NAME Labeller_TDUCT_start INPUT FEATURE_TYPE AttributeRounder_OUTPUT PLACEMENT UPPER_RIGHT LABEL_ENDS yes PLACEMENT_DISTANCE 0.0000001 PLACEMENT_SPACING 0 MINIMUM_LENGTH 0 REJECT_INVALID_GEOM YES OUTPUT POINT FEATURE_TYPE Labeller_TDUCT_start_LABEL @GeometryType(fme_text,@EvaluateExpression(FDIV,STRING_ENCODED,<at>Value<openparen>length<closeparen>,Labeller_TDUCT_start),0.000015,@Value(LabelRotation),ENCODED) @RenameAttributes(_label_rotation,LabelRotation) @RenameAttributes(_parallel_rotation,ParallelRotation)' is incorrect. The parameter to MINIMUM_LENGTH must be a constant value, a value-of (&) attribute, or an FME function call

Best answer by mark2atsafe

OK, from the log file above I strongly suspect that something was changed for 2016.1.1 and your client's version (2016.0.1) is incompatible.

I can think of a few fixes...

1) The obvious: have your client upgrade to 2016.1.1

2) Almost as obvious: downgrade to 2016.0.1 and recreate the workspace

3) Maybe not obvious: have your client replace that transformer in 2016.0.1.

4) Try the quotes thing, but I'm really not hopeful.

If everything else works then just replacing that transformer in 2016.0.1 should get around that issue. The problem is, how do you know that everything else works?!

I'll check with our developers about compatibility. For example, I understand that anything 2016 is obviously not guaranteed to work in 2015. But should 2016.1.1 workspaces work in 2016.0.1? Which digit of 201a.b.c.d is the point at which we assume compatibility is not guaranteed? I'll try and find out.

But generally, don't create (or edit) a workspace in a newer version and then run it in an older one. It's not good practice and it can cause problems of this type.

View original
    Did this help you find an answer to your question?

    10 replies

    itay
    Supporter
    Forum|alt.badge.img+17
    • itaySupporter
    • Supporter
    • September 13, 2016

    looks to me like a minimal requirement is not met (minimum lenght)

    jstanger
    Forum|alt.badge.img+1
    • jstanger
    • Author
    • September 13, 2016
    itay wrote:

    looks to me like a minimal requirement is not met (minimum lenght)

    I had thought the same thing from the error message, yet the node that is referred to in that message has the following properties when I sent the FME script:

     

     

    As far as I can tell they haven't edited anything. This is why I felt the need to ask since the error message doesn't make sense to me.
    itay
    Supporter
    Forum|alt.badge.img+17
    • itaySupporter
    • Supporter
    • September 13, 2016
    jstanger wrote:
    I had thought the same thing from the error message, yet the node that is referred to in that message has the following properties when I sent the FME script:

     

     

    As far as I can tell they haven't edited anything. This is why I felt the need to ask since the error message doesn't make sense to me.
    Strange indeed!, I would gather a 0 value to be a constant.....sounds like a support case to me...

     

     

    mark2atsafe
    Safer
    Forum|alt.badge.img+44
    • mark2atsafeSafer
    • Safer
    • September 13, 2016
    Can you confirm that you and your client are both using the same FME version? Can you specify the build numbers? That way if there is a difference I can check to see if something changed between those two builds. For example, I can see there was a change made in FME build 16422.

     

     

    Also, what are the two platforms? Both 32 or 64 bit? If you can paste the headers of each log file it would answer both this and the version questions.

     

    mark2atsafe
    Safer
    Forum|alt.badge.img+44
    • mark2atsafeSafer
    • Safer
    • September 13, 2016
    itay wrote:
    Strange indeed!, I would gather a 0 value to be a constant.....sounds like a support case to me...

     

     

    If I copy/paste a Labeller into a text editor I see: MINIMUM_LENGTH "0"

     

    I'm thinking that without those quotes FME might try to parse the whole thing as "MINIMUM_LENGTH 0 REJECT_INVALID_GEOM" being the name of a single directive. So I'm thinking a quoting error.

     

     

    mark2atsafe
    Safer
    Forum|alt.badge.img+44
    • mark2atsafeSafer
    • Safer
    • September 13, 2016
    Oh, also, is the workspace being run in the same build it was created in? Or was it created in 2015 but is now being run in 2016? That could be a source of a problem.

     

     

    jstanger
    Forum|alt.badge.img+1
    • jstanger
    • Author
    • September 14, 2016
    mark2atsafe wrote:
    Oh, also, is the workspace being run in the same build it was created in? Or was it created in 2015 but is now being run in 2016? That could be a source of a problem.

     

     

    Clients version header:

     

    2016-09-12 11:15:04| 0.6| 0.6|INFORM|FME 2016.0.1.2 (20160318 - Build 16178 - WIN32)

     

    2016-09-12 11:15:04| 0.6| 0.0|INFORM|FME_HOME is 'C:\\apps\\FME\\'

     

    2016-09-12 11:15:04| 0.6| 0.0|INFORM|FME MS SQL Server Edition (node locked-crc)

     

    2016-09-12 11:15:04| 0.6| 0.0|INFORM|Serial Number:

     

    2016-09-12 11:15:04| 0.6| 0.0|INFORM|Permanent License.2016-09-12 11:15:04| 0.6| 0.0|INFORM|Machine host name is: WVVMWKS26

     

     

    My version header:

     

    2016-09-12 02:58:33| 0.5| 0.5|INFORM|FME 2016.1.1.0 (20160722 - Build 16609 - WIN32)

     

    2016-09-12 02:58:33| 0.5| 0.0|INFORM|FME_HOME is 'C:\\apps\\FME\\'

     

    2016-09-12 02:58:33| 0.5| 0.0|INFORM|FME Database Edition (node locked-crc)

     

    2016-09-12 02:58:33| 0.5| 0.0|INFORM|Serial Number:

     

    2016-09-12 02:58:33| 0.5| 0.0|INFORM|Temporary License: 11 days left.

     

    2016-09-12 02:58:33| 0.5| 0.0|INFORM|Machine host name is: WIN-JM8060T7H42

     

     

    So it looks like build 16422 is smack in the middle of the two versions. I believe it was created in 2015, I've been modifying it in 2016 and the client has tried it on their copy of 2015 and 2016.

     

     

    I will also check if adding quotes allows the script to run on my dev environment.

     

    mark2atsafe
    Safer
    Forum|alt.badge.img+44
    • mark2atsafeSafer
    • Safer
    • Best Answer
    • September 14, 2016

    OK, from the log file above I strongly suspect that something was changed for 2016.1.1 and your client's version (2016.0.1) is incompatible.

    I can think of a few fixes...

    1) The obvious: have your client upgrade to 2016.1.1

    2) Almost as obvious: downgrade to 2016.0.1 and recreate the workspace

    3) Maybe not obvious: have your client replace that transformer in 2016.0.1.

    4) Try the quotes thing, but I'm really not hopeful.

    If everything else works then just replacing that transformer in 2016.0.1 should get around that issue. The problem is, how do you know that everything else works?!

    I'll check with our developers about compatibility. For example, I understand that anything 2016 is obviously not guaranteed to work in 2015. But should 2016.1.1 workspaces work in 2016.0.1? Which digit of 201a.b.c.d is the point at which we assume compatibility is not guaranteed? I'll try and find out.

    But generally, don't create (or edit) a workspace in a newer version and then run it in an older one. It's not good practice and it can cause problems of this type.

    mark2atsafe
    Safer
    Forum|alt.badge.img+44
    • mark2atsafeSafer
    • Safer
    • September 14, 2016
    mark2atsafe wrote:

    OK, from the log file above I strongly suspect that something was changed for 2016.1.1 and your client's version (2016.0.1) is incompatible.

    I can think of a few fixes...

    1) The obvious: have your client upgrade to 2016.1.1

    2) Almost as obvious: downgrade to 2016.0.1 and recreate the workspace

    3) Maybe not obvious: have your client replace that transformer in 2016.0.1.

    4) Try the quotes thing, but I'm really not hopeful.

    If everything else works then just replacing that transformer in 2016.0.1 should get around that issue. The problem is, how do you know that everything else works?!

    I'll check with our developers about compatibility. For example, I understand that anything 2016 is obviously not guaranteed to work in 2015. But should 2016.1.1 workspaces work in 2016.0.1? Which digit of 201a.b.c.d is the point at which we assume compatibility is not guaranteed? I'll try and find out.

    But generally, don't create (or edit) a workspace in a newer version and then run it in an older one. It's not good practice and it can cause problems of this type.

    The consensus of our "build and release" team is that the second digit is a "major" version change (eg 2016.0 to 2016.1) and that is definitely not guaranteed in the same way as 2015 to 2016 wouldn't be.

     

    The middle digit is a scheduled release but should only be fixes, so you should be able to switch between versions with a differing digit, provided you aren't using the functionality that needed to be fixed.

     

    The final digit is usually only for emergency hotfixes, so it's unlikely to be an issue unless you happen to be unlucky and are using the particular function that needed a hotfix (but if you did it likely wouldn't work at all in the older build anyway).

     

    jstanger
    Forum|alt.badge.img+1
    • jstanger
    • Author
    • September 15, 2016
    mark2atsafe wrote:
    The consensus of our "build and release" team is that the second digit is a "major" version change (eg 2016.0 to 2016.1) and that is definitely not guaranteed in the same way as 2015 to 2016 wouldn't be.

     

    The middle digit is a scheduled release but should only be fixes, so you should be able to switch between versions with a differing digit, provided you aren't using the functionality that needed to be fixed.

     

    The final digit is usually only for emergency hotfixes, so it's unlikely to be an issue unless you happen to be unlucky and are using the particular function that needed a hotfix (but if you did it likely wouldn't work at all in the older build anyway).

     

     

    Thanks Mark, I'll mark this as answered as irrespective of the final resolution I think the version incompatibility is the source of my issue. Good to know that in the a.b.c.d version numbering any change in "a" and "b" will likely cause issues.

    Reply


    Helpful Members This Week

    Community Stats

    31,340
    Posts
    118,850
    Replies
    38,929
    Members

    Latest FME

    Terms & ConditionsCookie settings

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings
    A product of
    Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.