The first issue is your VB program.
IF it is a "bare EXE" (no dependencies need be installed such as DLLs or OCXs), and
IF it only needs a few passive support files like text or image files that can be on the CD, and
IF the pre-installed MDAC on your clients' machines is "good enough" for your program, and
IF the pre-installed VB6 runtime on the clients' machines is
there and is recent enough (no obstructing bugs) for your program to run ok
THEN You may just get away with this.
The trick may be the MDAC version. Using DAO all bets may be off here. If you were using ADO instead, you might be able to get away with compiling against the "ADO 2.0" type library (if you don't use Record objects).
How To Develop with ADO Version 2.5 or Later and Install on ADO Version 2.0
All of that is in regard to the unrecommended practice of "XCopy deployment" of VB6 programs. I.e. where you don't use an installer (setup.exe, etc.) at all but want to run "bare VB programs." There may be other issues as well, but those are probably the highlights.
Regarding the database...
This WSH VBScript works fine and never requires an LDB (lockfile):
RO-MDB.wsf
Code:
<job>
<reference object="ADODB.Recordset"/>
<object id="rsRO" progId="ADODB.Recordset"/>
<object id="cnRO" progId="ADODB.Connection"/>
<script language="VBScript">
'The sample.mdb has a table called Names
Option Explicit
cnRO.Mode = adModeShareDenyWrite
cnRO.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=sample.mdb;"
rsRO.Open "SELECT * FROM [Names]", _
cnRO, adOpenStatic, adLockReadOnly, adCmdText
MsgBox CStr(rsRO.RecordCount) & " records"
rsRO.Close
cnRO.Close
</script>
</job>
It
does require an explicit ADO Connection object even if you could otherwise get by with just a Recordset.
The VB6 to do the same thing should be nearly identical.
See
ACC2000: How to Open a Database from Read-Only Media with Microsoft Jet 4.0 and ADO for ADO.
See
PRB: DAO MDB on Read-Only Media Must Be Opened Exclusively for DAO.
Note that DAO is largely an obsolete technology, though it does still do well for some specific types of application issues. In general you should probably have moved to ADO long ago though.