I do not explicitly use parameters here. The connections are adjusted to the server. This "Read Table 1" messages also appear if the dataflow runs correctly on the local machine. I think the problem is within the "Write QlikView 1" Operator, but it's just a normal operator which writes out the input without any changes.
I'm very curious as to why it would work in one environment but not another. Could be a bug in the Expressor server. But at least your error message is giving us an indication of where to look (I apologize if this is going to be a little rudimentary, but it might help someone not familiar with reading Expressor error messages. If you want to skip all the technical stuff just jump to the last paragraph.).
Something is going on in the "Write QlikView" Operator. But keep in mind that this is a static Operator. We can't go inside it to look at why it might be causing an error. Some Operators (like a "Transform" Operator) allow you to open it up look at the datascript. But we can't do that with the "Write QlikView" Operator.
This is where the error detail starts. This is just Expressor saying something went wrong in the 'initialize' function of the "Write QlikView 1" Operator.
Write QlikView 1 - OPERATOR-0050-F: toolId 2.0, name 'Write QlikView 1' - Exception 'RuleInstanceException' occurred in the 'initialize' function. (DataflowTest.Step_1)
This is a little more descriptive on what Expressor thinks the problem is. It also hones in on the location (in this case it is the rule 'Rule Write Custom'.
Write QlikView 1 - RULE_DESCRIPTOR-0020-A: The datascript rule 'Rule Write Custom' failed Datascript initialization. There is probably Datascript syntax error. (DataflowTest.Step_1)
This tells us exactly where Expressor errorred out and (if we are lucky) why it errorred out.
Write QlikView 1 - LUA_HELPERS-0018-A: Error LUA_ERRSYNTAX initializing Datascript: 'Rule Write Custom:1: unexpected symbol near '+''. (DataflowTest.Step_1)
In the first message (and if this were a "Transform" Operator) we could open it up and look at the "Initialize" Function of the datascript. But we can't open a "Write QlikView" Operator to view its datascript. So that's no help.
For the second message, Expressor datascripts are contained within "Rules". Each Rule is named. So if this were a "Transform" we could open it up and look at the Rule named "Rule Write Custom" to help locate the problem. But again we can't open up a "Write QlikView" Operator, so that's no help either.
Finally in the last error, it says: "Rule Write Custom:1". That means the error occurred on line 1 of the datascript Rule named "Write Custom 1". It's very specific as to the location and would be very helpful if this were a "Transform" Operator. But again, we cannot open a "Write QlikView" operator. So let's keep moving.
Still with me?
The actual thing that is raising the error is "unexpected symbol near '+' ". I don't know how much you know about Expressor datascript, so I won't get into it too much. But there are certain characters that you can insert into a perfectly valid line of text that will tell Expressor, "Stop doing things literally. I want to give you a special instruction before you continue." In Expressor, a couple of those characters are: backslash ( \ ) and percent ( % ). So let's say I had some FirstName records that I wanted to write to a database (or QlikView):
If I did this in datascript, Expressor would not interpret "Geo\rge" as "Geo\rge". It would actually interpret it as:
"Geo" + <a special instruction with the 'r' character> + "ge"
Now, if I did this with a plus sign ( \+ ), Expressor might say, "I know you are trying to give me a special instruction, but the plus sign is not a special instruction". And it would error out.
So... all of that said... I would first look at your source data that is coming in from the "Read Table 1" Operator. I have a feeling that there is some odd data in your source data. In one of your records, there may be one or more of the aforementioned characters right before a plus sign ( + ). Or there may be another character that I didn't even mention (likely it is punctuation). But if you search your source records for any text with a plus sign ( + ), you might find one or more odd characters and removing them from the record may prevent Expressor from erroring out.
Thanks, you was right in this point. The source table has some entries with "/".
But i tried with another test table which only includes numbers from 0 - 500.
And again local it runs without problems and through the QMC it failes again with the same errors as before with the "unexpected symbol near '+' ".
Eventually it is really some kind of bug or something else, but this only was a test.
Thanks a lot Paul.
I wonder if Expressor is using the plus sign as a concatenator behind the scenes. A lot of programming/scripting languages use the plus sign to concatenate strings, so that could very well be. So having plus signs in your source data might be irrelevant. It might be in the code. But something in your source data is causing Expressor to escape the string.
Now that I think about it, Lua Script (which Expressor uses) uses the plus sign to concatenate strings. Although the Expressor documentation indicates two periods (..) as a concatenator, I've accidentally slipped some plus signs into my datascript and it has worked.
Just thinking out loud.
In either case, I believe this is probably a bug in Expressor Server (since you said Expressor Desktop is handling it properly). The server is not properly escaping certain characters from the source data.
As for a remedy...
You said this was only a test. But in the event you run into this problem with data that you need to work with, I recommend trying to put a "Transform" operator before the "Write QlikView" Operator.
With the "Transform" operator you can use datascript to clean/normalize the source data before it reaches the "Write QlikView" Operator.
For example, you can use the string.replace() function to easily remove any backslashes from an incoming database field.
You may have to do that for a number of different characters, and it may be a lot of trial and error. But that's probably the quickest/easiest way to clean up data that is causing a downstream Operator to error out.