Unfortunately I suspect that the problem may be the same when you try to
connect using the Word User Interface - in other words, you do
everything correctly, but Word does not. Internally, Word will try to
connect using the method you select (if offered). If you don't specify
one, it will probably try OLE DB first, then possibly ODBC. In other
words, it may be necessary to use VBA to make the connection anyway.
Peter Jamieson
http://tips.pjmsn.me.uk
On 07/12/2009 14:50, Markus wrote:
Hi Peter,
Yes, I am same Markus. A little different issue here tho. In this case, I
am working with Word 03, and the problem is that I cannot get it to read a
dbf as a datasource directly within Word. Since I am using the Word menus to
set the datasource, the OLE syntax is not relevant here.
Doug's post helped me identify that the client has the odbc dbase driver
installed. Yet when I select that driver from within Word, it tells me it
cannot load the datasource. The dbf file is not corrupted, and I cannot
figure what other reason it has for not loading it, other than it is dbf
level 7 format. I will be trying more tests later today.
BTW, I tried dfferent syntax as you suggested on the previous problem I had
(using OLE to set the datasource for Word 07). Was not successful, but I
will return to it once I can get this client with Word 03 working.
Thanks again,
Mark
"Peter Jamieson" wrote:
(I recently had a conversation with another "Markus" on xBase
connectivity and wondered for a moment if you were the same one).
I wont be around for a couple of days, but
a. you may need to connect using VBA.
b. here's one of the messages I posted to him. If you use Google
Groups to look up "Peter Jamieson dBase" you may find other relevant info.
----------------------
I believe what is happening in this case is that
a. Word is trying to connect using the OLE DB provider
b. it either fails because that provider is not present or because the
table name is in the wrong format for the provider. The ODBC dirver
expects something like
Select * from MM.dbf
(this is what Word generates when you try to connect manually using ODBC)
but the OLE DB provider expects something more like
Select * FROM [MM]
or
Select * FROM `MM`
However, both the OLE DB provider and ODBC driver that I have here (as
it happens, it's the ACE provider/driver) accept any of
Select * FROM [MM]
Select * FROM `MM`
Select * FROM [MM.dbf]
Select * FROM `MM.dbf`
FWIW the error I see here is
"Error has occurred: The Microsoft Access database engine could not find
the object 'M.DB'. Make sure the object exists and that you spell its
name and the path name correctly."
i.e. the first and last characters of the name have been stripped.
I believe that Word will do (a) because you are specifying the .dbf
pathname in the Name parameter /and not/ specifying a Subtype parameter
equal to wdMergeSubtypeWord2000 (i.e. 8). As it happens, I thought Word
XP/2003 also did that,but perhaps the behaviour was slightly different,
or perhaps it used the OLE DB provider in those versions too, but the
unquoted file name worked in those cases. You can probably find out by
inspecting ActiveDocument.MailMerge.DataSource.connectString in Word
2003 (I wouldn't try in Word XP - it may still crash if you do that). If
the string starts with DSN, it's ODBC; if it starts with Provider, it's
OLE DB.
Here, I can get Word 2007 to connect using ODBC either by setting Name
to "", or by setting it to the pathname of the .dbf /and/ specifying the
wdMergeSubtypeWord2000 subtype value. FWIW at one time I think you had
to specify wdMergeSubtypeWord2000 in all cases where Name was set to
"", but I think an update modified that behaviour.
If it doesn't matter whether you use the ODBC provider or the OLE DB
driver, you could see if the dBase equivalent of
.OpenDataSource _
Name:="C:\wbdb\db3\KUNDNDB3.DBF", _
sqlstatement:="SELECT * FROM [KUNDNDB3]"
works on all the versions of Word you support after Word 2000.
All the above assumes that you can use the dBASE provider/driver (which
is part of Jet/ACE) and that you do not have to use the FoxPro
driver/provider, which is a different thing altogether.
FWIW the properties of the "dBASE Files" DSN here (Vista 32-bit SP1,
Word 2007 SP1) show that it is using the newer ACE driver. Modifying it
to use the older Jet driver made no difference to the behaviour of the
OpenDataSource code I tried here.
----------------------
Peter Jamieson
http://tips.pjmsn.me.uk
On 05/12/2009 03:03, Markus wrote:
Peter,
As I posted to David, it appears that thre are options on this client
computer for using an odbc connection to dbase datasource. But am still
getting "Unable to open datasource" when I try to manually connect the
datasource. Cannot figure why. Any ideas?
Thanks,
Mark
"Peter Jamieson" wrote:
This could be to do with how the "MDAC" (Microsoft Data Access) has been
set up. Version 2.5 had an ODBC driver for Foxpro, but version 2.6 did
not. You could have a look at
http://msdn.microsoft.com/en-us/vfoxpro/bb190233.aspx
Alternatively, if what you actually need is the VFP OLE DB provider,
that is definitely something that has to be installed - see e.g.
http://www.microsoft.com/downloads/d...displaylang=en
but there are probably still other versions on the downoads site.
You can inspect the ODBC setup by going to Control Panel-Administrative
Tools (it's listed in the "classic view"-ODBC Administrator. Or have a
look at
http://support.microsoft.com/kb/301202
Peter Jamieson
http://tips.pjmsn.me.uk
On 01/12/2009 18:19, Markus wrote:
With Word 2002, I have no problem using a dbf (level 7) as a dataource for
mailmerge. With Word 2003, a client is getting the message "Unable to open
datasource" when they try to set up a datasource for mailmerge using a dbf
(but with no reason given).
I have received info from other programmers that confirm their version of
Word 2003 seems to have no problem with a dbf. Is it possible that the
client's install of Word does not include an odbc driver for dbf files?
Wouldn't I get a different message in that case? Anyone know where I go in
Word 2003 to see if they have an odbc driver set up?
Many thanks for any and all ideas on this,
Mark
.
.