I'll start out with the short answer: No, never had this happen.
When you say, "the indesign proofs were correct," do you mean when previewing the data merge it was correct?
In any case, if you did preview the data merge, stop doing that and/or make sure you are not previewing when you have chosen to create the merged PDF/Document. Trust it will work. Preview can cause something "simple" like this to all out document corruption.
Did you merge to PDF (sounds like it) or did you merge to a new document? FWIW, I always merge to a new document, then create the PDF from it so I can review the merge in ID before the PDF...then I review the exported PDF, too.
Take care, Mike
Thank you so much for replying. No, we don't merge to a pdf, but to the in-design letter with the merge fields as part of the document and use a CSV database to merge the needed data. We do the merge, proof the in-design file on the screen, if all fields imported correctly, we then make a pdf of the in-design document we merged into.
The client always requires we sent 50 of the merged letters where they can proof them. So we take 50 letters from the in-design file, convert to pdf and email to client. The proofed records were all correct.
Then when we made the entire file, 7000 records, into a pdf, the 4-digits of the 9-digit zip code repeated in the merge field in the letter marked for the 4-digit account number. But we have tried several times to make this anomaly happen again and cannot. Each time, the data imports correctly and stays correct when we make the full file into a pdf.
Have you every hear of this happening? We just want determine if it was a freak glitch or if it was a software or operator problem. Then we know the procedures to put in place to either prevent it and/or proofing procedures to ensure we catch it if it ever happens again.
We have done this for years for this client without a problem.
Answer is still nope, never had it happen (thus far). I have no idea why it would have happened and not be repeatable in the same document.
But then, I have never had the preview bug, either. It is simply something which comes up often round here, so I asked.
Your issue, being that it couldn't be repeated, was either just something which was done differently that one time or perhaps a memory, computer related blip. Who knows.
Once the data is merged into a new document, merge fields are not "live" anymore. They have been replaced by the text of the data file. So I cannot imagine how data could be bunged up after the merge into the new file. It had to have happened during the merge somehow.
Are you saying you merge the file, then after the merge is run you do the proofing, or that you preview and then merge?
We merged the file, proofed on screen, made the pdf then printed the pdf. Data was correct on the in-design proof on screen, but when the pdf was made, the 4-digit account number was replaced with the 4-digit zip number. The only thing I noticed that I have not mentioned yet is that the field for the account number was named 4-digit. But the last 4 didgits of the zip code didn't have a separate fiend name. It was in with the full zip code under the header zip
But even if that had anything to do with it, why can't we make it happen again?
So you actually had a new, merged ID file in addtion to the template that exported differently than it was in ID? I don't suppose you rechecked the ID file after the export to see if it was still good?
Honestly, I don't have a clue how this could happen unless the file is damaged or you missed the problem while proofing.
I would need to see images of the merge file, the ID pre-merged document, the merge data panel, etc--or a sample file--in order to do any more guessing.
Every field needs a field name.