Mail Merge Speed - Lack Of

[Marcel Kollenaar]

RE: Mail Merge Speed - Lack Of

Scott, does MYOB start Word invisible? You can only trace this in the Windows Task manager. If that is the case MYOB can get the Word object much faster. Each merge call starts a new instance!?

Some questions:
a. Is ODBC involved with a mailmerge action? This also could introduce delay.

b. If Alpha follows the OLE rules maybe MYOB does nasty tricks with code which acts direct on the Word object model?

Marcel

[scottly]

RE: Mail Merge Speed - Lack Of

MYOB does not start word invisible that I can see (no winword.exe process running after starting MYOB). No SQL involved in the merge. I will keep digging on the MS side as time permits.

Regards,
Scott

[martinwcole]

RE: Mail Merge Speed - Lack Of

Scott, its been a while, but in 4.5 I found that using Alpha to export data to Excel and then calling the mail merge with a sys_ command was the fastest way to go. Just an idea.

[ChrisHawkes]

RE: Mail Merge Speed - Lack Of

Hi

To my knowledge MYOB uses a program called DRVWD32.EXE to pass the data to MS Word. I believe this to be OLE.

I may not be 100% accurate with this. but is the information I have.

Chris

[Selwyn Rabins]

RE: Mail Merge Speed - Lack Of

if MYOB is not starting word (visible or not), then how can it be using Word to do the mailmerge?

[scottly]

RE: Mail Merge Speed - Lack Of

The point was it does not start word before a mail merge is done - that is, it does not pre-load word when you start MYOB - but it does use word for a mail merge.

Regards,
Scott

[scottly]

RE: Mail Merge Speed - Lack Of

Thanks - I just noticed that the templates used by MYOB are .dot - this may suggest something to someone.

Regards,
Scott

[scottly]

RE: Mail Merge Speed - Lack Of

From what I can see, it 'seems' that MYOB uses macros - it installs some standard macros into word when installed and then when you tell it to do a mail merge and you select a template, it opens a .dot file and runs a macro to effect the merge (the macro must connect to a known temporary data source file created when the mail merge is requested) and runs the merge.

This probably means that for my alpha app I would need to create some standard documents (that the user can modify) that have a macro attached to effect the merge - and then in Alpha launch word and run the macro - but all speculation at this point.

The slow mail merge complaints mainly come from new users of my apps (others get use dto it once they work out it is only the first merge that is slow) - maybe it is just a matter of displaying a message saying if this is your first merge this session then be patient while M/S Word loads the mail merge 'function'. Depending on continued feedback from my users, I may further pursue the macro approach.

Thanks to those that have contributed to this discussion - I always strive to keep the users happy and sometimes that means more than just accepting the way Alpha tackles something by default.

[scottly]

RE: Mail Merge Speed - Lack Of

In the above, this was maybe worded poorly: "it installs some standard macros into word when installed" it should maybe say it installs word templates (which include macros)..

[Marcel Kollenaar]

RE: Mail Merge Speed - Lack Of

Scott,

That means that the simple start of Word is fast.

Way 1
If you create a template with the macro for the merge and put it in the wordstart directory the macro is always present when you start Word. You can simple call this macro and the merge is done.

Way 2
Another way is to make a template with an autostart macro in the This Document section which does the merge job. When you start Word, mention the name of this template on a Word startup switch. The template is opened and the startup macro is executed at once.

Marcel

[scottly]

RE: Mail Merge Speed - Lack Of

Thanks Marcel. I found out how to run a macro via OLE, viz:

app.run("members") ' run macro for a merge

Interestingly, I found that if I do not slow down the entire open template, merge, save as, print OLE process then the document would not print - not sure what that is about yet - seem sto run ahead of itself. So to save my merged doc and print it I use:

app.ActiveDocument.SaveAs(ws_mydoc)
app.activeDocument.printOut()
ws_waiting=wait_until(file.exists("dummyf"),1,1)
app.ActiveDocument.close()
app.quit(0)

Regards,
Scott

[Marcel Kollenaar]

RE: Mail Merge Speed - Lack Of

Scott, as far as I see you manage Word from A5 with ole. The processes of A5 and Word are asynchronous. So neither of the two do really know how far each of them is in the process and I do not know if A5 waits for the process it starts in Word and get a signal that Word is ready.

What you can do is create beforehand a ASCII delimited file and give the whole process of merging, saving, printing over to Word. That means that you have to start Word with a template that already has this macro in it. The only thing you have to do is start Word (if it isn't already started) and run the macro that does the work.

Or you can program a Word macro on the fly, see my topic Create a macro in Word with Xbasic code. Now you can manage the whole process with a macro build by Xbasic in Word.

Marcel

scott penrose wrote:
-------------------------------
Thanks Marcel. I found out how to run a macro via OLE, viz:

app.run("members") ' run macro for a merge

Interestingly, I found that if I do not slow down the entire open template, merge, save as, print OLE process then the document would not print - not sure what that is about yet - seem sto run ahead of itself. So to save my merged doc and print it I use:

app.ActiveDocument.SaveAs(ws_mydoc)
app.activeDocument.printOut()
ws_waiting=wait_until(file.exists("dummyf"),1,1)
app.ActiveDocument.close()
app.quit(0)

Regards,
Scott

[Finian Lennon]

RE: Mail Merge Speed - Lack Of

I've been doing what Marcel suggests (creating an ascii export file in A5) for about five years now and it's still going strong. It also incorporates his other suggstions all of which have worked great through successive versions of Word.

We have a series of template documents with embedded macros. The macros do post-merge formatting based on special characters sent to Word in the ascii file. [I take multiple lines from a one to many relationship - bill lines - and parse them into a memo field separated by a special character, prior to the merge. The macros can break them back out into an appropriate format after the merge.] The merge documents also have the list of available link fields embedded.

Every time a new user logs into the system, the user gets his or her own sub-folder and a copy of the template documents. Each user can then create new documents which always have the formatting macros and can choose from the list of merge fields as they wish.

I didn't want to use DDE when I first designed this, and now keep waiting to be forced into a redesign to uses OLE, but so far so good!

Finian

[scottly]

RE: Mail Merge Speed - Lack Of

Thanks for the description on what/how you do it - very helpful to know what methods others use.

Regards,
Scott

[scottly]

RE: Mail Merge Speed - Lack Of

Thanks Marcel. In deed I use OLE and it seems they are asynchronus. I do create the ascii file already but never thought to do the majority of the process in a macro (only the merge).

There are other options that the user chooses in terms of print Yes/No, and each processed record/merge gets saved to a unique document name which is controlled by data in my database - so the macro would need to change with each record merged (in terms of the name of the document to save). I am sure this is possible using your neat method of creating a macro on the fly - I would export an ascii record, create and run the macro, and repeat for each record to be processed in the merge - although I will still have an issue in regards to whether a prior 'run' was successful before starting the next.

I have spent a lot of time on investigating options - now that it seems that A5 does not wait for an OLE instruction to complete then the game changes again - always a learning experience.

Regards,
Scott