Runtime Access database

Skip to first unread message

Bill Baker

Feb 28, 2003, 4:43:37 PM2/28/03
Thanks for the quick reply Paul. I just want to be clear
about the file requirements:

Are there any other files required to support ADO access
to an Access database (mdb) on a system with a clean
operating system?

Thanks again,

>-----Original Message-----
>Bill Baker wrote:
>> I asked this question a few days ago, but I may not have
>> asked it correctly:
>> I need to know what (if any) files/utilities I will need
>> to utilize an Access database file (mdb) on systems
with a
>> clean operating system (Office/Access not installed),
>> if some additional files are required, where I would get
>> these downloads. I'll be running this script on Me, 2K,
>> and XP.
>> I'm currently having an issue on an XP system where as
>> soon as I try to loop through a recordset (Do While Not
>> RS.EOF), my script seems to hang (I have logging before
>> and after the Do line, and only the logging before the
>> line shows up).
>> This same script runs fine on other systems that have
>> Access (Office) installed.
>> Do I need to install MDAC, Jet 4.0, and/or anything else
>> on Me, 2K, and XP? Should I post this to another
>> since this is a scripting/database question?
>> Thanks again,
>> Bill
>Hi, Bill
>Your question about requirements might better be answered
in the ADO-related newsgroups. Post to the two to four
groups that seem
>most likely on topic, posting to all of them at once,
rather than separately. Makes it much easier for those
reading those groups,
>and easier for you too, since you can go to just any one
place to see responses from all of the newsgroups.
>To find your problem, search for any 'on error resume
next' ... 'on error goto 0' occurrences in your script and
make sure that
>these statements encompase the fewest lines of code
necessary. Since your program hangs with no error
message, the problem is
>probably occurring somewhere that error checking is
turned off.
>You might also try to pare down the script to something
really simple to find the problem. I use code as simple
as the following to
>find problems, adding in more stuff until the problem
becomes obvious. With error checking NOT turned off, I'm
just about
>guaranteed to get a helpful error message or a success
>Dim cnn 'As New ADODB.Connection
>Set Cnn = WScript.CreateObject("ADODB.Connection")
>cnn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
> "Data Source=.\NWind.mdb;"
>msgbox "Connection open was successful"
>-Paul Randall

Paul Randall

Feb 28, 2003, 5:48:26 PM2/28/03
Bill Baker wrote:
> Thanks for the quick reply Paul. I just want to be clear
> about the file requirements:
> Are there any other files required to support ADO access
> to an Access database (mdb) on a system with a clean
> operating system?
> Thanks again,
> Bill

Hi, Bill

Hopefully someone more knowledgable will be able to help. I don't know whether the stuff required for ADO is on the installation
disk for these OSs. I know that the amount of space used for a 'clean' install of the OSs you are interested in can vary by
hundreds of megabytes, depending on the type of install that you do. Perhaps someone knows exactly which options to choose in each
of them to get what you want. (Me, 2K, and ?XP Home or Pro?).

-Paul Randall

Russ Gray [MS]

Feb 28, 2003, 6:28:37 PM2/28/03

Hi Bill

It depends on the OS.

Windows XP comes with MDAC 2.7 and Jet 4.0 SP6 and has all the necessary
Windows 2K comes with MDAC 2.5 which includes Jet. If you're using this,
I'd recommend going to mdac 2.5 SP3 to get the latest files.
Me doesn't come with MDAC. ( I don't think, but we don't get many Me calls
) On Me I'd recommend MDAC 2.5 SP3 for the latest version of Jet, then go
to a more recent version for the improved ADO files.

But that's all you need, MDAC for ADO and Jet for Access. You might be
running something in the background that's interfering. Or, if this is a
Web based app and you're using the Jet ODBC driver, you may be hitting
thread safety issues. Jet ODBC isn't thread safe. Actually, if this is a
web based app, I wouldn't use Jet at all, even thru the OLEDB provider. Jet
has issues with concurrency and bloating that make it a bad choice for 24x7
high load apps.

I hope this helps,

Russ Gray
Microsoft Developer Support

This posting is provided “AS IS” with no warranties, and confers no rights.

Are you secure? For information about the Microsoft Strategic Technology
Protection Program and to order your FREE Security Tool Kit, please visit

Ronny Ong

Mar 1, 2003, 6:23:51 PM3/1/03
I wish I could give you a yes/no answer to your yes/no question, but there
can be many factors involved. On the one hand, Windows ME, 2K, and XP all
come with the Jet 4.0 OLE DB provider and Jet 4.0 ODBC driver, which give
you everything you need to access Jet-supported objects in MDB files using
Jet-supported SQL syntax. On the other hand, MDB files can contain both
Jet-supported objects and Access-specific objects, and Jet can execute SQL
syntax which is implemented by any combination of Jet, Access, and VBA. The
most likely problem is that your code is asking Jet to do something beyond
what Jet can support by itself.

What is the actual query that your problem Recordset is based upon? Does it
reference any linked tables, any pass-through queries, or (most likely) any
functions other than aggregations? Linked tables or pass-through queries
could be using ISAM drivers with versioning issues, or they might use Office
Data Connections which won't work without Office/Access installed. An
aggregation is a function like SUM() or MAX(), which is OK because Jet
implements aggregations internally, but if you use a function like
DLookup(), that's implemented by Access. If you use something like IIf() or
Left(), those are implemented by VBA. In those cases, Jet would be trying to
pass those off to Access or VBA to be evaluated. Depending on your query,
they might not be evaluated until you start retrieving data, which is why
you stop inside the Do as soon as you try and reference something in the
Fields collection.

Also, sorry if this seems too obvious, but are you sure you're using ADO and
not DAO? Both have object models have a "Recordset" object, but
ADODB.Recordset and DAO.Recordset are implemented by different DLLs. If
you're using CreateObject() in your script to instantiate all objects, there
would be no chance of mixing them up, but if you're using <reference> tags
in a *.wsf script, it might not be too difficult to confuse ADO and DAO
objects. A system with Access installed will always have DAO installed. A
system without Access can have DAO (installed from other products), but no
OS comes with DAO right out of the box. In contrast, Windows ME, 2K, and XP
all come with ADO right out of the box.

Assuming you're using ADO, what's your connect string? Are you connecting
with Provider=Microsoft.Jet.OLEDB.4.0, or are you connecting to MSDASQL (the
OLE DB provider for ODBC) and then specifying the Microsoft Access Driver
(or a DSN using that driver)? If you're using OLE DB without specifying the
4.0 version of the provider, try doing so. At the very worst, your script
will stop working on the machines that have Access, which will tell you that
you're using some Jet version-specific feature like an ISAM driver. If
you're going through ODBC and you don't have a reason, try changing your
connect string to use the OLE DB provider. If you do have a reason, then you
need to compare the version of ODBC driver you're specifying with the
version of your MDB.

If you isolate something that your code is doing which requires more than
just Jet, you can sometimes make minor changes to your syntax or logic to
avoid that. Even if you can't, there are several options for redistributing
varying pieces of Access (from DAO to OWC to a full runtime) without
licensing or installing Access.

Lastly, without knowing more about exactly what you're doing and what your
environment is like, it's also hard to rule out the possibility that maybe
your script isn't working on non-Access machines for reasons other than
Access being missing. Even though it sounds like you've got a variety of
non-Access machines, you might be in an organization which "Ghosts" or
images its desktop configurations. If something went wrong in creating the
images, you could wind up with a misleading pattern of machines exhibiting
the same problem. On your non-working machines, try applying Jet 4.0 SP6 to
make sure that Jet components are undamaged, as well as up to date. See to download Jet 4.0 SP6 for the
various operating systems.

"Paul Randall" <> wrote in message

Reply all
Reply to author
0 new messages