and dsn is new to me, as I usually use dsn-less connections. I dont

I've seen tiny bits of evidence that Word does set up DSN-less connections
itself in some circumstances but I've never been able to do it using either
OpenDataSource or the DATABASE field.

While a dsn isnt ideal it may actually work OK over VPN with a mapped
drive letter, I will have to test this. There may be some
authentication issues too.

Never had to try that myself so would be interested in the outcome.

Ideally I want the same solution (single distributed word file with
signed vba) for Word2K & 2002 Clients.

One problem you may face is that you may have to use the Subtype parameter
with OpenDataSource in Word 2002, certainly if you use a blank Name
parameter whereas it is regarded as invalid in Word 2000. I think you can
get around this in VBA by wrapping the calls in different subs/functions and
calling the correct one depending on the Word version. Another thing to
notice is that if you need to get tthe details of an existing connection you
can't usually do it in Word 2002 via the MailMerge.DataSource object because
of an error in Word. I suspect in your case neither of these things will be
an issue though.

Do you think its a bad approach to re-invent the wheel here and write
mailmerge type of functionality using code to create multiple instances
of a template and replace placeholders with adodb recordset fields .
....
Would this approach be any less efficient or more error prone for
clients, for 100 documents than a mailmerge ?

Generally speaking, I believe it is less efficient, but that would not
usually be my primary concern unless the merges were very large. I would
usually be more concerned with function (i.e. "does it do what is needed"),
stability, distributability (as you are) and maintenance. If you are
essentially using Word as a development platform with simple text
replacement facilities, and end users never need to modify the document
content, insert new "placeholders" etc. I think it's a good approach. As
soon as end users need to be able to tweak stuff, you need to be sure your
code is robust, they understand how the placeholder system works, and so on.
For example, in theory users can nest fields in the built-in mailmerge
system. You probably don't need to allow that but if you do, the coding
effort increases dramatically. Arguably, "rolling your own" merge code gives
you more control and makes certain types of merge simpler, e.g. when you
need to output one document per record in the data source, or one print job
per record in the data source (important if, for example, documents are
being stapled automatically by the printer).

Peter Jamieson

wrote in message
oups.com...
Peter, Thanks for the info on dsn.

It is surprising that word 2K doesnt use OLEDB for mailmerge.

The comments you made on my dsn working are probably true - it was late
and dsn is new to me, as I usually use dsn-less connections. I dont
reacall being promted for a location to store it so it must have been a
system dsn.

While a dsn isnt ideal it may actually work OK over VPN with a mapped
drive letter, I will have to test this. There may be some
authentication issues too.

Ideally I want the same solution (single distributed word file with
signed vba) for Word2K & 2002 Clients.

Do you think its a bad approach to re-invent the wheel here and write
mailmerge type of functionality using code to create multiple instances
of a template and replace placeholders with adodb recordset fields .
Something like this

strConn = "Provider=sqloledb;" & _
"Data Source=(local);" & _
"Initial Catalog=pubs;" & _
"Integrated Security=SSPI"
strSQL = "Select stor_id, stor_name from stores"

objConn.Open strConn
Set objRS = objConn.Execute(strSQL)
While Not objRS.EOF
Application.Documents.Add ("myTemplate.doc")
With Documents(Application.Documents.Count)
.Range.Find.Text = "STOR_ID"
.Range.Find.Replacement.Text = objRS(0)
End With
objRS.MoveNext
Wend

Would this approach be any less efficient or more error prone for
clients, for 100 documents than a mailmerge ?