mailmerge Excel Mail merge Problem (The never ending story...)

[MvS 5]

Hej i forumet!
Har tidigare ropat på hjälp med funktionen "mail-merge" i Excel men själv lyckats lösa de problemen. Det problem jag nu adresserar forumet med verkar lite knepigare och jag behöver få hjälp om det finns någon annan som har haft liknande problem och löst det.
BAKGRUND:

Har en databas jag gjort i Excel där jag behöver kunna skriva ut etiketter i en Word-mall som jag anropar med mail-merge i ett VBA makro. Både Excel-filen och Word mallen ligger i en mapp centralt på en nätverksplats. Excel-filen är utformad så att den sparas automatiskt på nätverket men också med en kopia lokalt på användarens HD. Meningen är att man ska arbeta på den lokala kopian och att den sedan uppdaterar på nätverket. Detta för att säkerställa att arbetsboken inte blockeras av en användare samt att det ska gå att jobba med databasen även i utrymmen där det inte finns WiFi.

Det innebär alltså att man ska kunna anropa Word-dokumentet från BÅDE filen på nätverket OCH från den lokala kopian vid behov, varför sökvägarna måste vara relativa. 

PROBLEMET:

När jag kör koden och kommer till själva mail-merge sekvensen ger Excel felsvar att strängen innehåller fler än 255 tecken! Varför sker detta?  Har testat både att ha alla mail-merge argument utskrivna i sekvensen samt, som i detta fall, att ange argumenten i variabler ─ utan framgång!

 

 

Har sökt med ljus och lykta efter svar på webben men det verkar inte som någon har ett bra svar att ge hur man kan komma runt detta problem! Skulle det kunna lösas med en systemfunktion eller ett makro som  tvingar Excel att skippa denna begränsning? Är min VBA felaktig på något sätt eller är detta en begränsning i Excel som inte går att åtgärda? Den enkla lösningen är ju att lägga all kopplings-kod i Word-mallen som körs när man öppnar dokumentet (vilket jag f.ö också har prövat) men då måste sökvägen vara absolut vilket inte funkar om man ska kunna etikettera från olika källor.

Bifogar även en kopia på makrot jag har problem med.

Med hopp om svar från forumet

 

//Magnus

 

 

 

Redigerad 28 februari av MvS

[Monshi 1 211]

Tror den där 255 tecken långa sökvägen är något du inte kan öka på att bli större.

 

Fungerar det inte med relativa länkar? Eller var ligger de olika dokumenten, Excel och Word? Inte relativt nära varandra?

Andra funderingen är hur ofta sker denna mailmerge? Inte som att det kan vara enklare att ladda hem filen när den ska köras?

 

Med det sagt, det finns även andra mer specialiserade program att skapa etiketter men det tror jag att vi varit inne på förr.

 

[polken 58]

Om det är sökvägen som är för lång(inkl filnamn) kan du välja ”mappa upp” den. Dvs ge den en enhetsbokstav i varje ansluten klient.  

T ex:
\\servernamn\nätverksmapp\undermapp\filen.xlsx
blir då t ex:

Z:\filen.xlsx

 

 

[MvS 5]

Hej Monshi och polken - Tack för era svar!
Monshi:
Förvisso kan man ladda hem filen varje gång men eftersom inventeringen görs löpande och arkivet 
ofta kompletteras med nya poster där serier och registerstruktur justeras regelbundet behöver det
vara automatiserat så mycket som möjligt.
Dessutom har jag vid tidigare tillfälle fått mail merge att funka med i stort sett samma parametrar
men då har jag varit på plats och kört det direkt från nätverket. Nu jobbar jag hemma med detta och
det är väl mest för min egen förkovran jag vill hitta en lösning så att verktyget kan användas även i andra sammanhang med vederbörliga ändringar.

Jag bifogar skriptet som det nu ser ut. Se även bifogad principskiss längst ner över de flöden jag vill ha!

'*****************************************************
' Öppna mall för hyllindex (Word-dokument)
'*****************************************************
Sub HyllMall()
    
    Dim mailMergeStr, SrcH, SQLSheetH, SQLSortH, SQLFilterH, SQLDataH, SQLH As String
    Call Modul1.DisableEvents
    Call Modul1.Uppdatera
    VarPath
    SQLSheetH = "[Hyllindex$]"
    SQLFilterH = "WHERE [Hylla] <> []"
    SQLSortH = "ORDER BY [11] ASC AND [2] ASC AND [3] ASC"
    SQLDataH = "Jet OLEDB:System database="""";Jet OLEDB:Registry Path="""";" & _
                                 "Jet OLEDB:Engine Type=35;Jet OLEDB"
    SrcH = fldPath & wdNameHylla
    SQLConnH = "Connection:=" & "Data Source=" & SrcH & ";"""
    SQLH = "SELECT * FROM" & SQLSheetH & SQLFilterH & SQLSortH
    mailMergeStr = SQLDataH & SQLConnH & SQLH                '
    frmSQLnotice.show
'    ---------------- Intiera Wordobjekt -------------
    Set objWord = CreateObject(Class:="Word.Application")
    objWord.Visible = True
    objWord.DisplayAlerts = wdAlertsNone
'    ---------------- Kör mailmerge -------------------
    Set wDoc = objWord.Documents.Open(SrcH)
    Set wdMailMergeH = wDoc.MailMerge
'    ---------------- Processa Mail merge -------------
    With wdMailMergeH
        .MainDocumentType = wdFormLetters
        .OpenDataSource Name:=SrcH & mailMergeStr
    End With
    Call Modul1.EnableEvents
    Call Modul1.Uppdatera
    Call Modul1.SkyddaBlad
    
End Sub

polken:
Jag har aldrig mappat tidigare... Vad är det och hur kan det hjälpa till med just detta problem? Excel protesterar ju även om jag använder fördefinierade konstant-strängar så det verkar handla om att informationen jag vill skicka till Word helt enkelt är för lång oavsett hur den överförs. Det torde väl bli samma resultat med mapping, eller? 

Principskiss över de flöden jag vill ha

Redigerad 28 februari av MvS

[Monshi 1 211]

inte.... funderat på att implementera detta i en databas istället btw?

[MvS 5]

Monshi

Jo,  det var det första jag övervägde men jag bedömde att organisationen skulle ha lättare att ta emot Excel...  Men att Access är ett för ändamålet bättre alternativ får jag hålla med om!
Jag tycker det ändå är märkligt, mist sagt, att Microsoft inte har kunnat lösa detta problem, och efter att ha sökt nätet efter svar på ett otal sajter kan jag konstatera att jag inte är ensam om att ha strul med detta fel samt att någon enkel lösning inte verkar stå att finna. 

Jag tänker mig i min enfald att man skulle kunna använda en VBA-funktion för by-pass av limiten - för att tala ren svengelska! Är det något du som verkar så beläst och insatt i VBA har någon uppfattning om? 

Som sagt, högst märkligt att man ska stupa på en sådan här irriterande detalj i ett annars så överlägset och mångsidigt program som Excel! Men nåväl, det är ju numer i huvudsak endast för min egen förkovran som jag tragglar med detta och alltid lär man sig något...

Jag tror att jag löser detta genom att lägga kopplingskoden i Word-mallen i stället då det har fungerat tidigare!
Tack för visat intresse i alla fall!

//Magnus

Redigerad 29 februari av MvS

[Monshi 1 211]

VBA är nog av Microsoft betraktat som ett nödvändig ont, en legacy-komponent, av Excel som de helst skulle vilja begrava.

 

Ett alternativ kan kanske ta den komplexa vägen, som MS försökte få in utvecklare på för några år sedan, att styra Excel via .Net.

Jag testade och lämnade det men där har du ett kraftfullare språk än VBA. Sen om det löser det eller om anropet ändå sker mot en komponent som lever kvar i det förgångna, det vet jag inte.

 

Polkens förslag är inte dumt men det gäller då bara lokalt på din dator, att alla som använda arket sätter upp på samma vis.

det du gör då är att du går till din nätverksenhet med utforskaren, högerklickar på mappen du vill mappa upp och väljer "lägg till nätverksenhet" och anger en enhetsbeteckning för denna.

Mmh, undrar om man med anrop in i windows api kan nå funktion som fixar detta via VBA... automatiskt..