Problem with JFMERGE using the last set of data on all form sets

Question

b Here is the scenario...
I have a file of data in character delimited format. Each record needs to produce the same set of forms. I used the Visual Transformation Editor to define the field nominated data file, including the ^form statements. The transformation agent processes the file of multiple records just fine. I get a file from JFTRANS that contains the set of data & form statements repeated for each record in the file.
Great so far.
b Here is the problem...
Unfortunately, the print agent is repeating the same set of data on every copy of the set of forms that is printed. It uses the data from the last set of forms to be printed.
b Additional information...
For ease of building the field nominated file by our custom client program we have standardized on using GLOBAL fields. Therefore, our DAT files contain all the ^global declarations with all the necessary ^form statements at the end. I used the transformation editor to build the same type of file. Therefore the file going to the print agent looks like:
^global name1
data1
^global name2
data2
^form form1
^form form2
^global name1
newdata1
^global name2
newdata2
^form form1
^form form2
The printed result puts "newdata1" & "newdata2" on both sets of form2. Strangely, the correct data values are showing up on both sets of form1.
The only difference between the two forms is that form1 is not defined with the fields as global where form2 does define them as global. I removed the global flag from form2 but that didn't change anything.
I think I know what is occurring. JFMERGE is putting the data elements into the global dictionary and when the same name is in the file the latest data value ends up in the dictionary (thus all the forms print using the last data put into the dictionary). I certainly didn't expect this. I thought it would load the dictionary and print the first set of forms, then reload the dictionary and print the next set of forms. At least that is the way I see it occuring based on the order of things in the DAT file. Based on what is occuring it appears that JFMERGE reads the whole DAT file, building the dictionaries and then processes all the ^form statements.
b My request for help...
Does anyone know what I can do (such as insert some command) to get the correct data on the forms?
It looks like using a fixed record format might do the trick but that isn't an option at this time. As things are right now it looks like I'm going to have to take the data file apart, and make lots of files with one line of data per file.
I have a time deadline to get this printed so if there isn't a way to make JFMERGE operate as I expected it looks like I'll be doing this by hand. Fortunately, there are only 250-300 data lines. Future jobs could have thousands of data lines so if there isn't a way to do it with a multi-line data file I'll have someone create a program for splitting the original file up (and adding the ^job line).

Answer 1

We don't use subforms so some of what you suggest isn't effective for us. Our forms are a duplication of the paper forms and are not dynamic. We design each form separately and our custom filler software (that builds the DAT file) uses a database with the required forms for each print job defined within it.<br /><br />Since we don't have subforms, our simple method of printing is to declare as GLOBAL all the unique fields used on all the forms to be printed followed by the ^form commands. It was a simple & straightforward method for us to do better than 500 print jobs over that past couple of years. In addition, our custom filler software can easily build the DAT files.<br /><br />Because I need to manually declare all the ^form statements my experience with using ^field is that the form must be declared followed by the appropriate field commands (repeat for all the forms).<br /><br />i <many hours later I continue typing this post><br /><br />Taking the original Transformation Definition File and customizing it for how things need to be when using ^field commands was a time consuming experience (and a learning one). It did the job as I needed but it is an experience I don't want to repeat. There has got to be a better way of building the TDF properly. I'm definately leaning towards a program to split the file into multiple files.<br /><br />Here is what I went through...<br /><br />I did all the editting using Notepad. I changed all ^global to ^field. Then I had to remove the #comment lines. Next was to find any references to fields that had to be global to the top and chang ^field to ^global. Then it was moving the fields around so they were underneath the appropriate ^form statement. Then, since one of the forms was multi-page I had to add the ^page command and sort the fields so they were under the correct page. That was followed by duplicating fields that are used on multiple forms or multiple pages. Then I discovered that the print agent won't do ^page unless "inline processing" is turned off (I did not want to specify the page name as it could change over time) - so I added "^inline off" in front of every ^page. Finally it was removing unecessary field references so the log file would be clean.<br /><br />For those that are interested, the following is an example of my final file. <br /><br />^global nameA<br />data<br />^global nameB<br />data<br />^form nameX<br />^field name1<br />data<br />^field name2<br />data<br />^form nameY<br />^field name1<br />data<br />^field name3<br />data<br />^inline off<br />^page<br />^field name4<br />data<br />^field name1<br />^inline off<br />^page<br />^field name5<br />data<br />^field name6<br />data