You are viewing limited content. For full access, please sign in.

Discussion

Discussion

Workflow Calculator - Invalid Numeric Value Warning

posted on January 23, 2019 Show version history

The Workflow seems to be calculating the numbers just fine.  But it returns the value as a string instead of a number.   I am getting the warning message:

Invalid Numeric Value:  Expression: %(LaborHours_Reg) + %(LaborHours_OT)*1.5 + %(LaborHours_DT)*2

Now each of these are tokens all set to Number, as well as the field being warned on running the calculation 'LaborHoursTotal'

The warning only exists when I pass an integer through as values.

No Warning Run Example:

%(LaborHours_Reg) = 4.00
%(LaborHours_OT) = 1.00
%(LaborHours_DT) = 0.00

Warning Run Example:

%(LaborHours_Reg) = 4
%(LaborHours_OT) = 1
%(LaborHours_DT) = 0.00

The return value is a string and my guess is that this invalid numeric is due to calculating integers where a float or decimal value is expected.

Is there a way to allow both or one step better.  Always convert value to decimal or float at calculation?

0 0
replied on January 23, 2019

I'm not seeing this issue. Are you sure the values are what you expect them to be? What is the complete warning message?

0 0
replied on January 23, 2019 Show version history

Here is the complete warning message.

The numbers are exactly what I expect them to be.

Here is an example of one of the variables from this equation:

The issue is these values come in from a text field.  Setting the tag to Number, I expected the behavior to be much like a CAST or CONVERT function where the type is changed.

It doesn't seem to be bothered by any string values that come in looking like a decimal, for example '1200.42'

Anything that comes in looking like an integer, '1200' behaves more like it remains a string or is converted to an INT over DECIMAL.

0 0
replied on January 23, 2019

"Error converting nvarchar to numeric" looks like your token is not being resolved or you have an actual string in there. Have you tracked your tokens at each iteration?

0 0
replied on January 23, 2019

Other iterations where the values have two decimal places I do not receive the warning.

The only location where the warning exists is when the user modifies the metadata before running the workflow and places integers in the place and doesn't add on the two decimals to the value.

The workflow will not run if these values are empty or blank so it's already guaranteed that the value will at least be 0.00 if no other value should exist.

0 0
replied on January 23, 2019

Is there a chance the user adds leading or trailing spaces to the value? Or some other character, like a line break?

1 0
replied on January 24, 2019

I haven't noticed any spaced after the values when checking through them.

But I added in a constraint on the field for decimal values. 

\d+.\d{2}

This should help control the type of data that flows into the workflow from the document.

I've double checked all the variables again and they are all set to Number and this value feeding in now should guarantee that it received a decimal type value.

It also may have been the Query run as well that gave the error to the database.  Even though I was calculating the value and receiving a warning, it was being set back to a String.

The type Default holds the type of the variable correct?  So in this case since the value coming in was most likely a whole Number, it would be setting the Type to Int?

I set this for always force the type to Decimal as I want for the database.

 

0 0
replied on January 24, 2019

The regex above allows for "12 45" or "12a45" because the period matches any character.

What is LABORQTY? Is that the resulting token from Token Calculator? If yes, that's unlikely to be an integer since you have a value multiplied by 1.5 in there.

Default in data queries means that the value will be left as-is and it is up to the driver and target database to interpret it.

0 0
replied on January 24, 2019 Show version history

Oh sorry you are correct, I have this expression:

\d+\.\d{2}

I'm using the literal character period.

LaborQty is the resulting token from the calculator correct.

Ok, even default or not I believe the result must have some either space like you mentioned.  No other tests have proven to replicate other than empty or space filled cases.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.