query mdb on network into Word. Access.exe not on workstation

  • Thread starter Thread starter R. Choate
  • Start date Start date
R

R. Choate

I have created a Word template that is just loaded with macros and userforms. Users on the network have a menu button in Word, which
opens a Userform in Word. The code behind the userform uses ADO to first check for a number of existing text files on their local
hard drive. If the text files don't exist, or if the user clicks on a "Refresh" button, then the code queries the Access db, which
is present on a network drive and then creates the needed text files with the data.

That was all fine and dandy until they started buying new workstations which don't have Access. They have the "Small Business
Edition" of Office. Now, they can't connect to the db and perform the ADO query against it. What can I do to make these work without
everybody having to get a full-blown version of Office on each PC?
 
If I understood your problem correctly, you probably don't have correct MDAC
installed on new workstations. You may also try to find and manually
register msado15.dll normally at "C:\Program Files\Common
Files\System\ado\msado15.dll" and dao350.dll or dao360.dll ("C:\Program
Files\Common Files\Microsoft Shared\DAO\")
 
To be as specific as I can, the users don't have Access on their workstations. They do have a runtime version I believe, that came
with some 3rd party app, but they don't have Access. The workstations have the "Small Business Edition" of Office, which does not
include Access. I think the MDAC thing is worth looking into. These are Office 2003 workstations and an Office 2K mdb. Please tell
me what I can look at here.

Thanks !

--
RMC,CPA


If I understood your problem correctly, you probably don't have correct MDAC
installed on new workstations. You may also try to find and manually
register msado15.dll normally at "C:\Program Files\Common
Files\System\ado\msado15.dll" and dao350.dll or dao360.dll ("C:\Program
Files\Common Files\Microsoft Shared\DAO\")
 
If you only need to access the database from Word to populate some fields
you don't need Access installed. DAO 3.5 should be installed with Windows
anyway, though it is not always registered properly.
If your database is created with Access 2000 or later, you will need to
install MDAC that contains DAO 3.6. I believe the latest MDACs (2.7 and
after) don't have DAO at all, but I may be wrong on this, check the
Microsoft site for details.
 
It occurred to me last night after thinking about your reply that the users really only need to have ADO, not DAO, and that they
also need to have a certain directory path available on their hard drive which I specify in my code to look for and to deposit text
files in, if the text files are not present already in that folder. It turned out that the new workstations did not have the
directory "C:/WINNT/TEMP", which is a normal directory from the first days of NT to the recent versions of XP Pro operating systems.
My code first attempts to look in that folder for 3 text files, and if they are not present, then my code creates them using
recordsets from a mdb on the user's network. By simply adding the "C:/WINNT/TEMP" folder, the problem was solved. The users already
have ADO 2.8 because it was installed with the Office installation. DAO was not an issue since I use ADO.

Thanks for your ideas. They led my thinking in the right direction.
--
RMC,CPA


If you only need to access the database from Word to populate some fields
you don't need Access installed. DAO 3.5 should be installed with Windows
anyway, though it is not always registered properly.
If your database is created with Access 2000 or later, you will need to
install MDAC that contains DAO 3.6. I believe the latest MDACs (2.7 and
after) don't have DAO at all, but I may be wrong on this, check the
Microsoft site for details.
 
Actually, ADO uses DAO internally while connecting to Jet databases. So in
this case ADO is just an extra layer of indirection, and extra overhead, if
you wish, though not very significant. You may test it yourself: try to
delete dao350.dll (or dao360.dll) and your code will blow up.
Simply renaming the files may or may not work because if Windows discovers
that you're renaming registered files, it will try to change the registry
entries accordingly.
 
Well, not sure that ADO uses DAO. ADO uses OLE DB provider for jet, and does
not require DAO. Access itself uses DAO anytime - this can be.
For example VB program connects to jet DB via ADO without DAO installed
 
Well I ran into this problem couple of times. If dao350 has not been
registerd, adodb provider for Jet did not know what to do.
 
I'm just hoping it doesn't come to worrying about DAO or about the MDAC. I think my solution will continue to work for all of the
new workstations, and that all they need is to have 2 folders added to their local drive. I haven't gotten any connection errors, so
I think my problem is licked. Thank you for making me aware of these possibilities should I run into trouble. I will use DAO if I'm
in Access and need more speed. Otherwise, if I'm querying data from outside data sources and if I can live with the speed ADO gives
me, then I'm using ADO. ADO is newer and offers some features that I like. I believe I can get to the data and get the results I
need with ADO more than DAO because I have invested more time learning ADO. I was told that MS is trying to phase out DAO and I
could find myself trying to help a client with a future version of Access where DAO is not supported at all. I'm sticking with ADO.

Thanks again,
--
RMC,CPA


Well I ran into this problem couple of times. If dao350 has not been
registerd, adodb provider for Jet did not know what to do.
 
Back
Top