locked
Lost the { SEQ name \n } code after a merge RRS feed

  • 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
  • Hi,
     
    As I have not heard from you for several days. I will go ahead and close this thread. If you have any questions, please feel free to reply to us and this thread will be re-opened.
     
    Best Regards, 
     
    Rex Zhang

    Rex Zhang

    TechNet Community Support

    Wednesday, March 28, 2012 7:57 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