please read and try these instructions before emailing me on how to do this!

if you are using a network, then each user should get their own front end. this code assumes a split mdb. if you don't split, then users will trip over each other with this code. for multi users, you must split the mdb to use this code.
 

usage:
in code on a form with a data source, just place the following command behind a button

          mergesingleword
          mergesingleword

that is it!!! one line of code!

you can also specify a dir for the above. this dir location is relative
to the location of your running application. this means that each application you have will default to a dir called word. if the directory does not exist, then the code will create the dir for you. this makes the whole process automatic, and no dirs have to be created at install time. the default dir is "word\". however, since several forms in a application will be based on different tables, then separating the templates to a separate dir for each form is a good idea (the users will not have to know what template belongs to what form).

usage is:
     mergesingleword [dir],[bolfullpath],[stroutputdoc]

example:
     mergesingleword "customers"

the above would use/create the templates in a dir called customers (relative to app dir).
the "\" is optional. if you leave out the "\", then my code appends a "\" to the dir name if you leave it out.

an absolute location can be specified as:
 

     mergesingleword "c:\myword\", true
 

the use of the true above forces the dir to be a full path name, and not relative
to the app dir. the path must be a full path, and not relative.
 

if you set the value of stroutputdoc, then the user does not have to supply a name for the resulting output document name.

if you need no prompts, and want to specify the from/to document name, then use

mergenoprompts strfromdoctemplate,[strdir],[bolfullpath],[stroutputdoc],[strsql],[bolprint],[strprinter]

    strfromdoc = name of template to merge from

    strdir  = optional - directory to use for templates

    bolfullpath = optional - if true, then strdir above is not relative

     stroutputdoc = optional - this sets the name of the output document

                             (if not set, then when user saves the word doc, then they will be prompted for the file name - this is the usual default behavior)
      strsql            = optional - this can be any sql/query to provide the data for the merge in place of the "one" current form.

      bolprint = optional - if set true, then the document is printed, and then closed. if you do not supply the stroutputdoc, then the merged document is closed and discarded.

     strprinter  = optional - a printer string to send the print to. this printer string does not change the currnet default printer. if left blank, then the current default printer is used.

another command that is used for "many" merge, and not just the current record is

mergeallword strsql,[strdir],[bolfullpath],[stroutputdoc]

the parameters above are the same as the previous commands. note that the sample download has an example of the "merge all" on the sample form. so, to merge all values from a table, you could go

dim strsql         as string

strsql = "select * from tblcustomers where city = 'edmonton'"

mergeallword strsql

it is that simple...

a few more points about this code, and ensuring reliable operation:

this code is late binding.
anyone who has any experience developing software will quickly realize that all automation code in ms-access should be late binding. late binding simply means that the references to word occur at run time, and not at compile time. since any developer worth their salt will realize this, then you should remove any references to the word object library in your application. you remove this reference via the same method where you just set the reference to dao 3.6 if running a2000 or later. hence, you do not need a reference to word to be set. if you do have a reference set to word, then you really are going to increase you chances of a broken reference problem in ms-access. this is especially so if you move your application to another pc. simply put, this is something you as a developer can control, so control it!!!..and use late binding.  broken references is one of the most common questions in the ms-access newsgroup, and there is no reason for this!! try and get rid of any additional references you have to word, or excel etc. you have control over this issue, and therefore you should take preventive measures, and reduce your support costs.

don't let word attached to you running mdb file.
again, this is just common sense. a large portion of word merge examples actually let word open your mdb file. this is a formula for disaster. allowing word to open the mdb file means that you have to deal with some known bugs (like word launching a second copy of ms-access for example).  further, if you implement security in ms-access, now word has to deal with passwords and permissions (again, a huge can of worms). worse is if you have the runtime of ms-access installed, or multiple versions of ms-access, then word can again cause all kinds of problems as it tries to launch ms-access, and it might even launch the wrong version of ms-access. i could again rant on for pages here, but i think any developer can clearly see that if we prevent word from trying to attach to the ms-access mdb file, then we avoid a ton of possible problems. again, since we can control this, then lets do so.  as a result, my sample merge code does not let word attached to the mdb file. as a result, it is rock solid. as a result, it just works!

of course what i do is create a temp txt file with the one record merged as a text csv file. note that i used to use a file name of merge.txt. however, it turns out that a bug exists in the word97 merge on pc's with file extensions hidden. the problem is especially noticeable on win xp machines, since hidden extensions is a common default for many users pc's. so, the solution here is to either turn on extensions, but that is hard to do.  it is way too much to ask users to re-configure their pc's to show file extensions. however, by using a file name with a non registered file extension, this known word merge bug can be avoided! thus, i now use a file name of merge.888, and this avoids this bug. if you need to use those merge files in excel, you can either change my code, as the file name used is a constant. you can also just re-name the temp file also.

my code uses the existing copy of word in memory.
it is silly to launch another copy of word if the user already has word loaded. why waste so much of the users computer resources if word is running all ready. there is no excuse for a developer to not use the existing copy of word in memory. of course, if word is not running, the my code does launch word. if the user is smart and leaves word running, then my code should reward those smart users and respect their wishes.  users will quickly find out that leaving word running means a faster load for the templates. and, if they like to close down word, then that is no big deal either. the key here is that the user can decide this issue.

conclusion:
the above list of concepts and ideas used for this merge is really common sense. so often people complain that their software is not reliable. further examining usually shows that the developer has adopted none of the above common sense suggestions.

you the are developer that writes bad and unreliable code. i find ms-access to be a very reliable and rock solid product if you use it correctly.

my access page

home page