I've never used the Insertdatabase method that Word records in this case,
but it's clearly broken.
If you want to use the Insert|Database approach, there are two ways to do
it:
a. insert the results of a database query as a table
b. insert the results of a database query as a { DATABASE } field that
results in a table.
When you record database insertion, the Insertdatabase method uses
LinkToSource:=False for (a) and LinkToSource:=True for (b). However, when
you use method (b), Word inserts a DATABASE field but fails to insert the \d
"the pathname to the database" switch, so the field cannot possibly work.
In other words, Insertdatabase does not appear to work for case (b). If you
want to do that, the simplest thing to do is insert a DATABASE field with
all the correct switches/parameters, then execute it. This may or may not be
the best approach to doing whatever it is you want to do.
Recording a macro that does (a) and executing it seems to work OK, but
notice that the connection string that Word builds for some database types
(e.g. Access) can be longer than 255 characters. Word will insert the
correct connection string when it inserts a DATABASE field, but truncates
the string to 255 characters in the recorded macro, and in that case you may
need to fix the connection string before the macro will work.
Other approaches to getting data into Word include:
a. set up the document as a Mail merge Main Document, and use VBA and the
facilities of the MailMerge.DataSource document to read the data from the
source and insert it into the document however you need. I would try to
avoid this because turning your document into a Mail merge main document is
likely to create plenty of difficulties, but the rason I mention it is
because the Mail merge Datasource object allows you to get data from any
data source that Word knows how to use, including text files, word
documents,Access, Excel, ODBC and OLEDB data sources.
b. use VBA and ADO, assuming your data source has a suitable OLEDB
provider.
Peter Jamieson