Answered by:
Lost the { SEQ name \n } code after a merge

Question
-
Hi,
I have a document with { SEQ list name \n } codes. After I merged this document I lost these codes and the number got literal. I thought I put them between {} (Ctrl+F9) field codes like {{ SEQ list name \n }} but this wasn't the solution. Both codes disappeared. I thought that with the first merge the outer field codes were evaluated and in the result the code inside was left just as it was.
Is this by design and if yes is there another possibility to keep the { SEQ list name \n } after a merge?
Kind Regards,
Marcel
Tuesday, March 20, 2012 4:05 PM
Answers
-
Hi marcel,
Anything that uses a bookmark (as does the SEQ field) gets converted to literal text during a mailmerge. So, no, a SEQ field won't survive a mailmerge.
Dedpending on what you're trying to achieve, you may be able to implement a workaround based on the MERGEREC field, though. This increments for each record. This can either be output as literal text or embedded into some other field code for evaluation.
Cheers
Paul Edstein
[MS MVP - Word]- Marked as answer by Rex Zhang Wednesday, March 28, 2012 7:58 AM
Wednesday, March 21, 2012 8:00 AM
All replies
-
Hi marcel,
Anything that uses a bookmark (as does the SEQ field) gets converted to literal text during a mailmerge. So, no, a SEQ field won't survive a mailmerge.
Dedpending on what you're trying to achieve, you may be able to implement a workaround based on the MERGEREC field, though. This increments for each record. This can either be output as literal text or embedded into some other field code for evaluation.
Cheers
Paul Edstein
[MS MVP - Word]- Marked as answer by Rex Zhang Wednesday, March 28, 2012 7:58 AM
Wednesday, March 21, 2012 8:00 AM -
Hi,
We cannot reproduce the issue in Word 2010 with SP1 installed. The code won’t be lost after a merge.
What’s your version of Word?
Do your merge the documents by Insert > Object > Text from File…?
Did you test it with new created documents?
Where do you put the field in?
Can you reproduce the same issue if you insert another filed such as {PAGE}?Please inform some details for further test.
Sincerely
Rex Zhang
--------------------------------------------------------------------------------
Forum Support
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.- Edited by Rex Zhang Wednesday, March 21, 2012 8:55 AM
Wednesday, March 21, 2012 8:55 AM -
-
Hello Rex,
Sorry not replying in time. There was a hurry on this issue and made a work around.
My version is Office 2010, Word version: 14.0.6112.5000 (32-bits) Dutch.
I tested is also with clean new documents on another computer with the same Word version. The field was inserted in the main text stream and should survive a merge in such way it should also work in the result of the merge which it didn't.
The merge is as follows: I have a template with macros in it. This starts a merge with an Excel sheet with data resulting in a merged doc with several "docs" in it. Then another macro split this up in single documents and after splitting a specific part in the result document is duplicated several times the amount of a value that was put in the Excel sheet. In this splitted result the SEQ field must increment the amount of the duplication, eg if the part was duplicated 4 times the text should read declaration 1, declaration 2, declaration 3, declaration 4. In this result document (straight from the merge) nothing survived that looks like {...} fields, even the page codes are lost. I made a work around and that was acceptable in my case.
Below a small part of the code that starts the merge:
ActiveDocument.MailMerge.OpenDataSource _ Name:= _ DataSource, _ ConfirmConversions:=False, _ ReadOnly:=False, _ LinkToSource:=True, _ AddToRecentFiles:=False, _ PasswordDocument:="", _ PasswordTemplate:="", _ WritePasswordDocument:="", _ WritePasswordTemplate:="", _ Revert:=False, _ Format:=wdOpenFormatAuto, _ Connection:= _ "Provider=Microsoft.Jet.OLEDB.4.0;Password="""";" & _ "User ID=Admin;Data Source=DataSource;Mode=Read;" & _ "Extended SQLStatement1:="", _ SubType:=wdMergeSubTypeAccess Properties=""HDR=YES;IMEX=1;"";" & _ "Jet OLEDB:System database="""";" & _ "Jet OLEDB:Registry Path="""";Jet OLEDB:Datab", _ SQLStatement:=sqlSt, _ With ActiveDocument.MailMerge .Destination = wdSendToNewDocument .SuppressBlankLines = True With .DataSource .FirstRecord = wdDefaultFirstRecord .LastRecord = wdDefaultLastRecord End With .Execute pause:=False End With
When the splitting is done I insert the SEQ code with VBA.
Sub InsertSEQ(strAantalDeclaraties As String) Dim BlijfZoeken As Boolean BlijfZoeken = True If Val(strAantalDeclaraties) >= 1 Then While BlijfZoeken = True Selection.Find.ClearFormatting With Selection.Find .Text = "#" .Replacement.Text = "" .Forward = True .Wrap = wdFindStop .Format = False .MatchCase = False .MatchWholeWord = False .MatchAllWordForms = False .MatchSoundsLike = False .MatchWildcards = True End With Selection.Find.Execute Replace:=wdReplaceNone If Selection.Find.Found Then Selection.Fields.Add Range:=Selection.Range, Type:=wdFieldEmpty, Text:= _ "SEQ declaratie\n ", PreserveFormatting:=True Selection.InsertAfter " van " + strAantalDeclaraties Selection.Collapse Direction:=wdCollapseEnd Else BlijfZoeken = False End If ActiveDocument.Fields.Update Wend Else With Selection.Find .ClearFormatting .Text = "#" With .Replacement .ClearFormatting .Text = "" End With .Execute Replace:=wdReplaceAll, Format:=True, MatchCase:=True, MatchWholeWord:=True End With End If ActiveDocument.Fields.Unlink End Sub
Kind regards,
Marcel
Tuesday, April 17, 2012 2:30 PM -
Hi Marcel,
As I said in my first post, SEQ fields don't survive a mailmerge. Furthermore, where the merge creates new Sections (as in a letter or label merge), the SEQ-based numbering will re-start at 1 (or whatever the initial starting # was) for each new Section. Depending on what you;'re trying to achieve, this limitation can be overcome with formulae based on the MERGEREC field and/or a SECTION field. Given that you're apparently splitting the merged output into separate documents, a solution based on a MERGEREC field would probably be the one to use. No vba is necessarily required for the numbering.
FWIW, the 'ActiveDocument.Fields.Unlink' in your code wipes out any SEQ fields in the output document.
Cheers
Paul Edstein
[MS MVP - Word]Wednesday, April 18, 2012 6:03 AM -
Hi Paul,
Thanks for your answer. Yes, the fields don't survive a merge, tested it again. That the document is split was a user demand. After the plit I put the {SEQ} codes at "#" positions for those parts that are duplicated (one or more declaration forms) and do a field update and after that I make the field results literal, thats the .Unlink method. This works very well in this situation. I could have used a counter var in vba but al the building blocks were there and the mindset and was at that moment the most obvious way to accomplish it.
Kind Regards,
Marcel
Wednesday, April 18, 2012 9:54 AM