Thanks for the reply, shong.

I upgraded to v3.2.2, rebuilt some of the components, etc. but still the same behavior: I can only connect one row input to tFileOutputMSPositional. Any other inputs I try to connect are refused (using the GUI, I select the row output on the tMap, then drag over to the tFileOutputMSPositional, but the plug icon shows a circle with the cross through it, showing that it cannot connect).

(I have not tried v4.0.x yet, preferring to wait until it's marked stable/production-ready.)

Is there maybe another way to make the connection? Or something that has to be configured first?

Re-reading the components reference guide, it talks about how the table of schemas will be automatically filled in when inputs are added, but that you need to configure the dependencies between them. In my case, there are no dependencies--it is just a header row, a handful of data rows, and then a footer row. Maybe there's a better way to do this? For example, I could make 3 separate positional files, the concatenate them together. But the tFileOutputMSPositional sure seems like the right component for the job...

Last edited by ewall (2009-12-29 15:55:05)

Yes, that's it! It didn't like having 3 inputs from the same source (see picture #1).

Once I copied and split out the input file into 3 separate pieces, I was able to have all inputs go into the final tFileOutputMSPositional (see picture #2). However, that gives me some strange errors:

HeaderOutput cannot be resolved to a type
Syntax error on token ".", class expected after this token
DataOutput cannot be resolved to a type
Syntax error on token ".", class expected after this token

It appears that some lines of the output code don't get filled in correctly:

HeaderOutputMap_tFileOutputMSPositional_1.put(String.valueOf(HeaderOutput.), HeaderOutput_tFileOutputMSPositional_1);

I wonder if this is because I haven't filled in the tFileOutputMSPositional component's fields for parent row, key column, etc. (since there is no such relationship between the rows)?

I did find a work-around, though... I used another set of tMaps to concatenate all the fields into a single 145-character field, which makes them all the same schema so I could join them with a tUnite and write to the output file (see picture #3). Should I stick with this solution, or is there a way to fix the errors in #2?

Last edited by ewall (2009-12-30 19:08:23)