Just wanted to post a possible bug. If it is how it works then that is fine but wanted to mention it in case others ran into it.
We are doing a Custom Query activity that writes to a clients SQL table. The error message we were getting is "Error converting data type nvarchar to numeric".
We use many other Custom Queries through the process but this happened to be the first time the SQL fields were of type int.
The values we were writing to these tables were just numbers. However these values are actually coming from the workflows input/output variables since the workflow was being Invoked from another.
The issue is, the values are not always going to be there. Sometimes they will not have an ID and that is fine, we want it to write 0 or Null to the database. What we found was that since the tokens were coming from the workflows input/output parameters it was not actually empty. It was actually passing the variable name.
We changed the field in SQL from int to nvarchar so we could see what WF was attempting to write to the SQL table. In the red box below, we saw that it actually wrote %(Dental Benefit App instead of the value of the token. The full token name was cutoff due to length restrictions. We cleared the database so I don't have a screenshot of the actual variable write. The 0 is there now because it is fixed but imagine that instead of 0 it said %(Dental Benefit App
So it seems that even through the Track Tokens shows that the value is empty.
It was actually trying to write the token name to the DB. This only seems to happen if what you are writing to the table happens to be a variable from an input/output parameter from an invoked workflow. Writing values from variables or within the same workflow were normal.
After testing, the only way around this was to set tokens. We set the tokens equal to the input/output parameters.
They still show nothing but now it seems that the query writes the actual value to the DB instead of trying to write the token name.
Not sure if that is how it should work or if it is a bug. Just thought I would post in case it could be looked at or if anyone else runs across the issue.
Thanks,
Chris