[...]

Hi, Robert.

I don't know if Word allows merging from a Recordset object directly but as I
have no clue on how to link to an LDAP catalog directly without coding, I first
tried building a connection string using ADO. As all my attempts in Visual
Interdev were unsuccessful, I wanted to do it step by step.

My first step was more of a proof-of-concept. Just to make it clear on how I
should setup my own query. Then I planned to used it somehow in word for my
mailmerge. I'm still there :).

Vince C.

Thanks for raising this, especially as I'd forgotten that Word will work
with .udl files.

.odc (Office Data Connection or Office Database Connection) files are in a
sense very similar to .udl files in that they encapsulate a connection
string. However,
a. .udl uses the old .ini file syntax of having a [Section name] followed
by the connection string, e.g. for the ADsDSOObject the data link editor
seems to create a file containing
[oledb]
; Everything after this line is an OLE DB initstring
Provider=ADsDSOObject;Encrypt Password=False;Mode=Read;Bind Flags=0;ADSI
Flag=-2147483648

(as far as I know the first two lines should always be the same in a .udl,
but since the second line is a comment it is difficult to see why it has to
be there)
b. .odc wraps the connection string in XML (and uses HTML/XML "escapes" for
characters such as double-quotes) and wraps that in an HTML file
c. .odc contains other information, e.g. the "command" (typically a table
name or an SQL string, the type of command, and the type of thing (table,
whatever) the .odc is designed to fetch. As far as I can tell, when Word
OpenDataSOurce uses a .odc, it will use the SQL specified in the
OpenDataSource rather than the SQL in the .odc
d. the main point of this seems to be that the "results" of a .odc file can
be viewed in IE. This relies on some additional "behaviours" defined in a
file called DATACONN.HTC
e. since I found it quite difficult to work out how the information in an
OpenDataSource and a .odc combine I experimented with cutting stuff out of a
.odc, discovering that the simplest approach from a test point of view is to
have a completely empty one. But using a .udl is probably even more
straightforward.

To create a .odc in Word 2002/2003, when you get to the Select Data Source
dialog, you can either click on the +COnnect to New Data SOurce.odc or +New
SQL Server Connection.odc file names, which are typically listed in the My
Data Sources folder under your My Documents folder, or you can click the
New Source Button. To use an arbitrary OLEDB provider you can then select
Other/Advanced, select the provider and you should be seeing the same dialog
as you see when you double-click on a .udl. The only difference seems to be
that when you actually save the connection info., it is saved in .odc
format.

(Vince has said that he's just using VBS to test). As far as I know there is
no way to use a "disconnected" (in-memory) recordset as a data source for a
merge. I can't imagine how you would even identify it if it was created in
another process. But since it is possible to use ADO to save and re-open
recordsets to disk (e.g. in XML format) I suppose that in principle it would
be possible to use an OLEDB provider to re-open the recordset and provide
the data to Word. The question is whether any of the existing providers can
do this using the information that you can store in a Word OpenDataSource,
and/or a .udl or .odc. Although I suspect the answer is "no", partly because
I think you have to use the Persistence provider in conjunction with the
relevant data provider and I'm not convinced that it would be possible to
set all that up in a connection string+a command (e.g. SQL statement)
a. I don't know for sure
b. I can't think of any reason why it would not be at least theoretically
possible to create an OLEDB provider to do it, or even a Word converter. I'd
attempt the former, except it looks quite difficult to create a provider
without grappling with COM and (realistically speaking) C++, neither of
which I especially want to spend time grappling with. I'd attempt the latter
as I already have a non-C++ basis for writing converters, but I'd probably
only be able to do it on a commercial basis.

--
Peter Jamieson - Word MVP

Vince (and Robert if you have an interest in this too):

I have now run into a similar "data type" problem to the one you
encountered. When I use OpenDataSource try to SELECT any field except * from
the records I'm trying to retrieve from Lotus, the value is blank. If
instead I get the data via ADO and  RecordSet, and specifying a field such
as cn in the SELECT, VBA fails whenever I try to access the Value property
of the Field (e.g. rsPerson.Fields("cn").Value). When I look at the field
type, it is 12 (apparently Variant), which should allow me just to use e.g.
CStr() to return the string. But it just doesn't work. Unless someone has a
really bright idea I'm currently inclined to say "It's a nice idea, but too
many programmability/compatibility issues stand in the way of making it
work". Unless there is a relevant setting in e.g. Lotus that can specify the
column's data type, I suspect using OpenDataSource is never going to work,
which would rule out a mailmerge direct from the data source. Using LDAP to
do an export via ADO might still be feasible but it may be easier to do the
necessary export some other way.

--
Peter Jamieson - Word MVP