Calling on all MS-Word Guru's

[TTT]

We are building a database solution for a large client and need to buil
complex reports with Word.

To paint a picture:

The database solution we are building creates a data file which is use
in the merge process. We launch a template and macro, and a ne
document is created based on the data within the data file. This al
works well.

We need to extend this functionality and do some complex stuff wit
mail merge (or any other method if necessary).

We need to produce a report (i.e. the Word document), which is
collection of data from different tables/sources.

The report will have different sections such as Employment History an
Education History (and more). These sections are really individual mai
merges themselves, which read data from different sources.

The sections will have a series of fields on a single page - and eac
record within the data file will merge into its own page - we're no
bringing them into a table.

This isn't too complex, but that's not where the problem lies.

If you imagine several sections similar to that described above, eac
requiring a different data source, and then all this merged into on
document.

It's almost like we're trying to "Include" smaller merges into a large
one, just like you would use "Include" in HTML or other programmin
languages.

We figure that we might need to perform each section as individua
merge documents, and then some how bring these files into the mai
one.

We've even toyed with the idea of creating the sections as MS-Wor
Objects embedded into the main document. Which sounds kind of right
except we couldn't figure out how to trigger the merge within th
embedded object. Triggering the merge manually within the embedde
document tries to create a new document - which screws up ou
automation process.

OK - lots to digest - Assistance is greatly appreciated.

Thanks. :rolleyes

 

[Peter Jamieson]

If you want to build on top of standard mail merges, you will almost
certainly end up using VBA to stitch together the results. I'd say when it
gets this complicated it's probably simpler to regard the project as a
non-mailmerge Word VBA project where you get your data from your sources
using e.g. ADO.

The main drawback is that unless you really work hard at generalising your
code, you will lose end-user facilities such as the ability to edit the
template/skeleton documents at will, and sort/filter facilities. But my
guess is that you probably don't need or want much flexibility in either of
those areas.

By using a mixture of "boilerplate" text in one or more Word douuments, and
placeholders, which might be bookmarks, you can probably keep the VBA code
fairly simple (i.e. you don't have to use VBA to construct the entire
document from nothing).

I guess if you're using Word 2003 you might consider using SmartDocuments
instead, but I can't help you much on that front at present.