Re: QRe: Legacy Access 2 VB 4 app, Word 11 merge on XP Pro SP2 client

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: david epsom dot com dot au (david_at_epsomdotcomdotau)
Date: 01/31/05 

Date: Mon, 31 Jan 2005 11:04:10 +1100

One file seems to indicate that the App was installed as a VB5
application (vb5db.dll). The other files indicate a
Win32 application (VB4 included separate VB16 and VB32 versions.)

The file list also includes the Jet 3.5 or 3.51 engine (the
file names were the same), which may indicate that the database
had been upgraded from Jet 2/2.5 to Jet 3.5/3.51. Jet 3.5
was part of Office 97, so perhaps the application was written
in VB4 with Access 2.0, and later upgraded to VB5 using Office
97 (Word 97 and an Access 97 database).

None of the files listed here need to be installed: they all
look like standard windows files. (Standard Windows installations
seem to include the Jet 3.5 and Jet 4.0 files right now).

And the files you listed as unregisterable are mostly not important
or already exist in other versions.

ODBC was the default data access method for Word97, so there could
be a potential problem there, but on your description the dat
data file is a Text file, either RTF (a Word table), CSV (comma
separated variables) or tab separated. Those text formats are
native Word formats, so no ODBC connection would be used from
Word to the dat file. Also, ODBC mail merge was not part of
Office 6, so it is unlike in an application updated from Office
6 to Office 97.

If your VB program is successfully exporting the data to a text
file, you can be sure that none of those Jet files matter.

Since the OLE files are all OLE32 (not 16 bit files), you can be
sure that they are not required on a modern copy of Windows.

This is a VB program to echo the command string of the call to
Winword: you would compile the program and call it instead of
Winword.exe

Sub main()
    MsgBox "command string: " & Command$
End Sub

:) obviously, the devil is in the details, :) but you can do
the same in any other programming language.

The error messages indicate that Word is starting correctly
(probably VB is starting the listed executable, because OLE
was never that reliable!), but is having trouble opening
a file (either the dat file or the destination file). The
'object' error typically means that there is no File Object,
and indicates that a file didn't open correctly.

One thing that you haven't said that you tried: Make sure the
path does not include any 'long' parts. Configure the application
to send the .dat file to something simple like c:\ If necessary,
run the application from c:\ if that will help you simply the data
path.

Because Tab separated data is a native Word format, it should
work without any data connection problems. The other two methods
of accessing data, (OLEDB and ODBC) both use the Jet database
engine to access text. This is indirect and more complex, but the
real problem is that in it's current default configuration, Jet
won't open text files with the .dat file extension. You can check
to see if this is causing the problems by enabling the .dat file
extension for text files through Jet. You need to make a registry
change to do that: add 'dat' to the 'DisabledExtensions' list at
HKLM\Software\Microsoft\Jet\4.0\engines\text

Sorry about the long message: I only set out to make a brief
comment, and just kept on adding to it...

(david)

"John Nurick" <j.mapSoN.nurick@dial.pipex.com> wrote in message
news:taunv0ttse35djosg45i1uq9d2drihej16@4ax.com...
> <snip>
>
> >I researched the install.log of the application and found many "errors"
such
> >as the following.
> >The following files were not installed:
> >C:\Windows\Systeme32\Vb5db.dll
> >------same path-------- \Stdole.dll
> >------same path-------- \Stdole2.tlb
> >------same path-------- \P2sodbc.dll
> >------same path-------- \Olepro32.dll
> >------same path-------- \Oleaut32.dll
> >------same path-------- \Odbctl32.dll
> >------same path-------- \Odbcjt32.dll
> >------same path-------- \Odbcji32.dll
> >------same path-------- \Odbc32.dll
> >------same path-------- \Ms*.dll including jet35, and Msvbvm50
> >Also Mfc42.dll and Mfc40.dll and many ODBC*.dll, .exe .cpl, .cnt.
> >
>
> This is emphatically not an area I understand. Could it be that the
> files couldn't be copied because they already existed? The one thing is
> that for DDE and OLE the application wouldn't normally need the name and
> location of winword.exe.
>
email.

Relevant Pages

  • Re: QRe: Legacy Access 2 VB 4 app, Word 11 merge on XP Pro SP2 client
    ... Also the Edit form option opens Word with the master merge document ready ... the data source .dat file is created properly and obviously ... (Standard Windows installations ... you can be sure that none of those Jet files matter. ...
    (microsoft.public.access.conversion)
  • Re: QRe: Legacy Access 2 VB 4 app, Word 11 merge on XP Pro SP2 client
    ... The app is currently configured to send the .dat file to the location of the ... > ODBC was the default data access method for Word97, ... > native Word formats, so no ODBC connection would be used from ... you can be sure that none of those Jet files matter. ...
    (microsoft.public.access.conversion)
  • ADO failing on XP - untangling MDAC and Jet DLLs
    ... My ADO based app is working fine on hundreds of PCs, ... ADOConnection object can be created and that Jet 4.0 is correctly ... on older PCs with corrupted MDAC installations the app would ... nicer and then I can get the user to install MDAC etc. ...
    (borland.public.delphi.database.ado)