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

[ITJRW]

I have a network where all of the client machines were recently replaced and
are now running XP Pro SP2. Office 2003 is also on the new machines.

The legacy application was written in VB 4 and I have no source code
available. The Access version is 2.0. The application works as expected
and as it did before the upgrade with the exception of Microsoft Word
merging capabilities. The application creates a proper ".dat" merge
document but is unable to do the link. The .dat file contains a properly
generated header with the field names tab separated and the data from the
requested record (by entering the keycode value in a message box) tab
deliminted as well. The data is what it should contain.

The setup settings are properly directing the application to the correct
directory path and winword.exe file name. Word does not open and three
errors occur in succession according to the messages that appear:
In the title bar of the message box: "Merge Error (Word) #1056 and in the
center of the message box: "Not a valid filename."
Clicking on the OK command button brings up another error message box with
the title bar showing "31031 (0)" and the text in the message box being
"Invalid Source for link"
Clicking in the OK command button brings up another error message box with
the title bar showing "31004(0)" and the text in the message box being "No
object."

The document is a valid document and the path is correct. I have written a
workaround macro in VBA of Word to allow them, after responding OK to the
three messages in the legacy Access app, to press Alt-M in an open,
no-document Word application which presents them with the directory
containing the master merge document and containing the newly created data
source .dat file containing the header and record data as requested in the
legacy app. After selection of the requested file, I test the file name of
the .doc file and create a DataSourceFileName for .dat files over 8.3 and
then do the merge of the document to a new file with the .dat file created
and given as the source for the master document. This process proceedes
without a problem. I suspect that there may be some ODBC connectivity
problems between the legacy apps that don't know OLE and that are looking
for another type of data source other than ".dat" files. This was the old
way of providing a data source from which to merge via ODBC (to fake it out)
and the older DDE application connectivity.

I do not have the old app source code, the developer are not at all
interested in updating to anything later than Access 97 (believing that Bill
Gates is out to destroy them <bg>. Is there anything I can do, other than
writing a new application, to allow the users to merge with this old
application to Word v. 11? I have no problem accessing the tables via a
DSN-less SQLConnect() statement but the record comes through some 24 steps
in a "Logic" table in a different database than the actual data. I have
been doing database programming for 17 years but have little, brief
experience with Access but quite a bit with VBA, Visual FoxPro, SQL, and C.

Any suggestions would be greatly appreciated? The work around is getting
the users to the goal line but it's taking too many downs to do make the
touchdown.

Justice

 

[John Nurick]

Hi Justice,

I'm not quite clear what the situation is. It sounds as if the
application was developed in VB4 and automated Word 6 via DDE (or OLE?)
for this mailmerge. You mention Access 2.0; does that mean that the
application also automated Access 2.0 or simply that it uses the Jet
database engine (i.e. .mdb database files)?

Do the new computers have Access 2.0 installed on them, or Access 11, or
both?

Either way, there has been significant change in the Word mailmerge
object model since Word 6.x (contemporary with Access 2.0), and my first
suspicion is that this is the cause.

It would be worth posting this question in one of the Word newsgroups in
case there's a known solution there.

Failing that, it might be possible to improve your work-round along the
following lines. It sounds from what you say that the legacy app is
trying to use DDE to control Word.

1) Build a "dummy" application (maybe in VB6) that impersonates Word 6
to the legacy application. You'd include the dummy's filename in place
of "winword.exe" in the legacy app's setup settings. In the
proof-of-concept version, the dummy would simply be activated by Windows
when the legacy app tries to activate Word, accept any messages it
received, and quit at the end of the conversation; i.e. it would be a
sort of "DDE sink".

This should allow the legacy app to create its .dat file without
producing any error messages.

2) If you can get that working, the next stage would be to modify the
dummy so it parses the .dat file name and any other necessary data out
of the messages it receives, fires up Word 11 and performs the merge.

 

[ITJRW]

Hi John,

Let me first say, I really appreciate the depth of your response--both in
the questioning and the suggestions. Thanks.

As to the questions, I may not be able to answer all the questions without
some more direction. However, let me give them a try. But before I address
the DDE, OLE, Jet issue, let me say that the workstations do not have any
Access version installed on them. The legacy application was developed and
compiled (with and .exe and several .dlls) using Access 2 (.mdb, .ldb, etc.)
and Visual Basic 4. There are no macros that I know of that were
interacting with DDE (as I'm familiar with at my office where legacy
UNIX/Universe Data Base apps do merge via DDE and recent versions of Word.
I suppose that would suggest the Jet database engine is what the Access 2.0
app is using.

A brief description of how the merge takes place might help you know better
than I what it is using. By the way, I have the legacy application
installed on my development machine (OS=XP Pro SP2 and Office 2003 Pro -- so
I do have Access 11 installed and have downloaded and installed the Access 2
converter) and have reproduced the problem here as well. That is, in fact,
the way I developed the macro to use as a work around. Now, the brief
description of how the app merges:
The user clicks a command button on the legacy app which presents them with
a form selection window containing the path of the document to merge and the
path of the word processing app (standard path to winword.exe has been
verified and tested with a "Run" feature on the "File" pulldownmenu). A
form is selected by number or by it's form descrition and when the user
clicks an OK command button, they are presented with a window containing a
textbox to enter the keycode (primary key) of the case record they want the
merged document to contain. The click OK on this message window and are
asked on another window to enter a primary key value for a specific person
involved in the case. When they click on OK the error windows appear as
described in the previous post (see below). In case it was not clear in the
previous post, the application _does_ create the
<sometimes-short-merge-document-filename>.dat file using the name of the
merge document the user selected.

Is it probable that, if DDE is being used, all of the processes are coded in
the exe or dlls? Or, could there be a version issue with the Jet engine
that could be dealt with?

I will post as you suggest to the other newsgroup.

I'm not real sure how to go about what you are suggesting but I think you
may have a great idea here. Let me see if I understand correctly. I
replace the string to the path of winword.exe with another application
executable which would simply receive the messages from the app and flush
them down the "DDE sink" (itself) and then call Word 11 with arguments to
run my macro at startup. I would modify my macro to use the filename that
is passed to the dummy to open as the master merge document and do the stuff
I'm already doing to associate the data source file the legacy app created
with the merge file and do the merge. If that's correct, wow! I wish I'd
thought of that.

The only problem is that I don't have a clue how to impersonate Word 6 in
VB6 (I still have Visual Studio 6.0 installed, however I'm more comfortable
in Visual FoxPro or Visual Studio.net and either VB.net or C#.net using the
..net framework. Would it be possible for you to point me to some sample
code or document that might guide me down the path or could you respond with
a few lines of pseudocode?

In any case, you have been extremely helpful in pointing me to the right
direction. Thanks again.

Justice

 

[John Nurick]

Let me first say, I really appreciate the depth of your response--both in
the questioning and the suggestions. Thanks.

A pleasure: it's an interesting problem.

As to the questions, I may not be able to answer all the questions without
some more direction. However, let me give them a try. But before I address
the DDE, OLE, Jet issue, let me say that the workstations do not have any
Access version installed on them. The legacy application was developed and
compiled (with and .exe and several .dlls) using Access 2 (.mdb, .ldb, etc.)
and Visual Basic 4. There are no macros that I know of that were
interacting with DDE (as I'm familiar with at my office where legacy
UNIX/Universe Data Base apps do merge via DDE and recent versions of Word.
I suppose that would suggest the Jet database engine is what the Access 2.0
app is using.

If the workstations don't have some version of Access installed on them
and the legacy app runs at all, it *cannot* be an Access application,
but is almost certainly a VB4 app that uses the Jet database engine. (It
makes no difference if Access was used to *create* the mdb files in the
first place.)

Are you sure that when you install the legacy app it doesn't instal a
run-time version of Access 2? I'm labouring this point because if Access
isn't installed on the workstation this isn't an Access problem at all,
rather one involving a VB4 app failing to control Word 2003.

A brief description of how the merge takes place might help you know better
than I what it is using. By the way, I have the legacy application
installed on my development machine (OS=XP Pro SP2 and Office 2003 Pro -- so
I do have Access 11 installed and have downloaded and installed the Access 2
converter) and have reproduced the problem here as well. That is, in fact,
the way I developed the macro to use as a work around. Now, the brief
description of how the app merges:
The user clicks a command button on the legacy app which presents them with
a form selection window containing the path of the document to merge and the
path of the word processing app (standard path to winword.exe has been
verified and tested with a "Run" feature on the "File" pulldownmenu). A
form is selected by number or by it's form descrition and when the user
clicks an OK command button, they are presented with a window containing a
textbox to enter the keycode (primary key) of the case record they want the
merged document to contain. The click OK on this message window and are
asked on another window to enter a primary key value for a specific person
involved in the case. When they click on OK the error windows appear as
described in the previous post (see below). In case it was not clear in the
previous post, the application _does_ create the
<sometimes-short-merge-document-filename>.dat file using the name of the
merge document the user selected.

I don't understand what you mean by

Is it probable that, if DDE is being used, all of the processes are coded in
the exe or dlls? Or, could there be a version issue with the Jet engine
that could be dealt with?

If the rest of the app is working it's unlikely to be a Jet issue.
That's why I'm focussing on the DDE or whatever else the VB app may be
using to control Word.

I will post as you suggest to the other newsgroup.

I'm not real sure how to go about what you are suggesting but I think you
may have a great idea here. Let me see if I understand correctly. I
replace the string to the path of winword.exe with another application
executable which would simply receive the messages from the app and flush
them down the "DDE sink" (itself) and then call Word 11 with arguments to
run my macro at startup. I would modify my macro to use the filename that
is passed to the dummy to open as the master merge document and do the stuff
I'm already doing to associate the data source file the legacy app created
with the merge file and do the merge. If that's correct, wow! I wish I'd
thought of that.

I'd envisaged having the "dummy" app receive and parse the messages and
then use (modern) automation to launch Word and perform the merge, with
the code running in the app rather than in a Word macro. I feel this
approach gives you more control than simply launching Word with
command-line arguments (particularly when it comes to trapping errors
and UI matters generall). But if you've got the command line approach
working, you may be able to stick with it.

The only problem is that I don't have a clue how to impersonate Word 6 in
VB6 (I still have Visual Studio 6.0 installed, however I'm more comfortable
in Visual FoxPro or Visual Studio.net and either VB.net or C#.net using the
.net framework. Would it be possible for you to point me to some sample
code or document that might guide me down the path or could you respond with
a few lines of pseudocode?

The first thing is to find out how the VB4 app is communicating with
Word 6. I never really used VB4 and can't remember where it stood in
relation to OLE, but the fact that the app wants to know the location of
winword.exe suggests that it may just be building a command line and
passing it to the shell. In that case, the impersonation is merely a
matter of setting the path to your dummy app in the legacy app's setup.
You could test that by setting the path to some innocuous executable
like notepad.exe instead of that to winword.exe; if an attempt to merge
from the app then launches Notepad, you'll know it's using the
shell+command line approach.

Otherwise, things will be more difficult and are beyond my experience. I
guess it'd be a matter of installing some sort of snooper software to
see what's happening (www.sysinternals.com ?). After that, you'd
presumably have to spoof some registry entries.

If it's a command line, just about any language should do the job
including your favourite scripting language. If DDE or OLE it will have
to be something that has the necessary libraries.

Good luck; even though it's probably not an Access issue I'd be
interested to hear how you get along.

In any case, you have been extremely helpful in pointing me to the right
direction. Thanks again.

Justice

 

[ITJRW]

A pleasure: it's an interesting problem.

Indeed. I find it a challenge. I would simply write a short interim app as
a temporary merge from DSN-less SQLConnect() (which I've been able to
successfully connect to the .mdb files and access the tables) into a cursor
containing only the data desired. However the data is collected from
several tables via over 24 records of steps in a "Logic" table. I suspect
it may be placing them into a cursor long enough to create the .dat file but
don't know for sure. I just know that it uses three of these logic record
sets to retrieve the data. I would suspect that I may not have any
restriction on doing this if I make the cursor read-only with Sequal Pass
Trough approach. I guess I could locate the data in the original records of
the various tables and create a SQL statement to retrieve all of these
values and add my own he/she his/her values based on a "Sex" field value.

Bottom line here is that I am developing a replacement application with new
interfaces and tables and will ultimately bring these records into my own
structures since the lady who developed the app is unwilling to update it
and the client has asked me to develop a new app with more features anyway.
I've been working on it alone since last August. It's mighty robust.

If the workstations don't have some version of Access installed on them
and the legacy app runs at all, it *cannot* be an Access application,
but is almost certainly a VB4 app that uses the Jet database engine. (It
makes no difference if Access was used to *create* the mdb files in the
first place.)

Are you sure that when you install the legacy app it doesn't instal a
run-time version of Access 2? I'm labouring this point because if Access
isn't installed on the workstation this isn't an Access problem at all,
rather one involving a VB4 app failing to control Word 2003.

Where would I look for the runtime and what is it called? I assume it is a
dll. Since I have Access 11 and the Access 2 converter on my development
machine, do you believe I could identify it with certainty without going to
the next county about an hour away for me?

I don't understand what you mean by
<sometimes-short-merge-document-filename>.dat

I mean that if the name of the merge document is longer than the old 8.3
standard the .dat file is given the short file name. Examples:
"Indictment.doc" named merge document will cause the app to create
"Indict~1.dat" and "Motrev.doc" named merge document will cause the app to
create "Motrev.doc" I hope that is a bit clearer.

If the rest of the app is working it's unlikely to be a Jet issue.
That's why I'm focussing on the DDE or whatever else the VB app may be
using to control Word.

The application is performing exactly as it did on Windows 98 machines and
NT 4.0 server in all respects except the merge doesn't even open MS Word 11,
much less merge. The application used to open Word with the merge document
merged into a new document with the data source (.dat file) providing the
data for the merge fields. When they upgraded to OS XP Pro and Office 2003
Standard the merge was "broken." Therefore, you must be right.

I have posted to several Word newsgroups as well.

I'd envisaged having the "dummy" app receive and parse the messages and
then use (modern) automation to launch Word and perform the merge, with
the code running in the app rather than in a Word macro. I feel this
approach gives you more control than simply launching Word with
command-line arguments (particularly when it comes to trapping errors
and UI matters generall). But if you've got the command line approach
working, you may be able to stick with it.

Your concept would, indeed, be preferrable.

The first thing is to find out how the VB4 app is communicating with
Word 6. I never really used VB4 and can't remember where it stood in
relation to OLE, but the fact that the app wants to know the location of
winword.exe suggests that it may just be building a command line and
passing it to the shell. In that case, the impersonation is merely a
matter of setting the path to your dummy app in the legacy app's setup.
You could test that by setting the path to some innocuous executable
like notepad.exe instead of that to winword.exe; if an attempt to merge
from the app then launches Notepad, you'll know it's using the
shell+command line approach.

Otherwise, things will be more difficult and are beyond my experience. I
guess it'd be a matter of installing some sort of snooper software to
see what's happening (www.sysinternals.com ?). After that, you'd
presumably have to spoof some registry entries.

If it's a command line, just about any language should do the job
including your favourite scripting language. If DDE or OLE it will have
to be something that has the necessary libraries.

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.

Most of the above I've checked and they were'nt installed due to newer
versions being on the machine.

In addition the install would not self register the following:
vbajet32.dll, vb5db.dll, stdole2.tlb, p2sodbc.dll, several ODBC??32.dlls,
msjter35.dll and msjter35.dll most of these because they could not be copied
to the <system>\System32\folder. I have administrator rights and so did the
users when the application was installed on their machines (now they don't
since I installed a W2K3 server and improved security matters).

I believe this problem is a typical "dll hell" problem from what I'm seeing.

I don't know if this would give you any insights into what the application
is using since there are dlls for ODBC, OLE, and Jet.

Good luck; even though it's probably not an Access issue I'd be
interested to hear how you get along.

Thanks again for jumping in even though it may not be an Access problem.

 

[John Nurick]

Indeed. I find it a challenge. I would simply write a short interim app as
a temporary merge from DSN-less SQLConnect() (which I've been able to
successfully connect to the .mdb files and access the tables) into a cursor
containing only the data desired. However the data is collected from
several tables via over 24 records of steps in a "Logic" table. I suspect
it may be placing them into a cursor long enough to create the .dat file but
don't know for sure. I just know that it uses three of these logic record
sets to retrieve the data. I would suspect that I may not have any
restriction on doing this if I make the cursor read-only with Sequal Pass
Trough approach. I guess I could locate the data in the original records of
the various tables and create a SQL statement to retrieve all of these
values and add my own he/she his/her values based on a "Sex" field value.

I'd think of it in terms of creating an Access 2003 database and using
linked tables to connect to the data in the legacy .mdb files. But it's
largely a question of the tools one's used to.

Bottom line here is that I am developing a replacement application with new
interfaces and tables and will ultimately bring these records into my own
structures since the lady who developed the app is unwilling to update it
and the client has asked me to develop a new app with more features anyway.
I've been working on it alone since last August. It's mighty robust.

Where would I look for the runtime and what is it called? I assume it is a
dll. Since I have Access 11 and the Access 2 converter on my development
machine, do you believe I could identify it with certainty without going to
the next county about an hour away for me?

No, it's not a DLL but essentially the whole of Access 2.0 with the
design-mode capabilities disabled. Search your workstation's HD for
msaccess.exe. If you find one that's the wrong age and the wrong
location for your Office 2003 installation, with other Access files in
the same folder, that's probably it.

I mean that if the name of the merge document is longer than the old 8.3
standard the .dat file is given the short file name. Examples:
"Indictment.doc" named merge document will cause the app to create
"Indict~1.dat" and "Motrev.doc" named merge document will cause the app to
create "Motrev.doc" I hope that is a bit clearer.

That makes sense.

The application is performing exactly as it did on Windows 98 machines and
NT 4.0 server in all respects except the merge doesn't even open MS Word 11,
much less merge. The application used to open Word with the merge document
merged into a new document with the data source (.dat file) providing the
data for the merge fields. When they upgraded to OS XP Pro and Office 2003
Standard the merge was "broken." Therefore, you must be right.

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.

Most of the above I've checked and they were'nt installed due to newer
versions being on the machine.

In addition the install would not self register the following:
vbajet32.dll, vb5db.dll, stdole2.tlb, p2sodbc.dll, several ODBC??32.dlls,
msjter35.dll and msjter35.dll most of these because they could not be copied
to the <system>\System32\folder. I have administrator rights and so did the
users when the application was installed on their machines (now they don't
since I installed a W2K3 server and improved security matters).

I believe this problem is a typical "dll hell" problem from what I'm seeing.

I don't know if this would give you any insights into what the application
is using since there are dlls for ODBC, OLE, and Jet.

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.

 

[ITJRW]

Thanks so much for the help, John.

I'd think of it in terms of creating an Access 2003 database and using
linked tables to connect to the data in the legacy .mdb files. But it's
largely a question of the tools one's used to.

Is there an article you could cite that would guide me through the process
of doing the above ("creating an Access 2003 database and using linked
tables to connect to the legacy .mdb files."). I'd like to further research
that as a possible solution at least on an intermediate basis.

No, it's not a DLL but essentially the whole of Access 2.0 with the
design-mode capabilities disabled. Search your workstation's HD for
msaccess.exe. If you find one that's the wrong age and the wrong
location for your Office 2003 installation, with other Access files in
the same folder, that's probably it.



That makes sense.





This is emphatically not an area I understand. Could it be that the
files couldn't be copied because they already existed?

That _is_ why they couldn't be copied, but that wouldn't explain the
inability to register them unless they were already registered as well.
This could be.

The one thing is
that for DDE and OLE the application wouldn't normally need the name and
location of winword.exe.

I could not get the app to accept the changes to Notepad within the
application. I will try to do this in a converted, separate set of the same
files and see if I can change it in the mdb file table that contains the
word processor information. The option is there for a Lotus product and
Word Perfect as well. I should be able to write the path to a different
value for these and use them as a fakeout for testing.

Again, you have been the most help I've had on this and a great
encouragement to try here again in the future. Are you one of the ones who
monitors this newsgroup for rapid responses to MSDN and other users?

Justice

 

[John Nurick]

Is there an article you could cite that would guide me through the process
of doing the above ("creating an Access 2003 database and using linked
tables to connect to the legacy .mdb files."). I'd like to further research
that as a possible solution at least on an intermediate basis.

It's so simple that I don't know an article. The general idea is to
create the database by launching Access 2003, going to File|New, and
selecting "blank database" or some such. Then use File|Get External
Data|Link Tables to link to tables in the legacy app's mdb file(s). Once
you've done that the tables are available within the new database. This
approach - front end with UI and logic in one mdb file and tables in
another - is standard practice in Access development. Access 2003 will
work happily with a back end in an older format.

One possible complication is security. I don't know what was common
practice in VB apps in those days, but from the Jet end it was and is
possible to set a simple password on a whole mdb file, or to achieve
stronger and finer-grained access control via "user-level security". the
latter is implemented via a "workgroup file", a database of users and
permissions, usual extension .mdw.

If the legacy app asks for usernames and passwords and has installed a
..mdw file, and if you get "access denied" errors when you attempt to
create the linked tables, user-level security is a likely cause. In that
case, make sure you have a backup of the .mdw file, then launch Access
2003 using the /wrkgrp command-line switch to pass the name and location
of the workgroup file.

I could not get the app to accept the changes to Notepad within the
application. I will try to do this in a converted, separate set of the same
files and see if I can change it in the mdb file table that contains the
word processor information. The option is there for a Lotus product and
Word Perfect as well. I should be able to write the path to a different
value for these and use them as a fakeout for testing.

Again, you have been the most help I've had on this and a great
encouragement to try here again in the future. Are you one of the ones who
monitors this newsgroup for rapid responses to MSDN and other users?

Not specially. This is very much peer-to-peer support; one hopes you'll
be able and willing to help someone else some other time and/or place.

 

[ITJRW]

Thanks so much for your help. I should be able to attempt a trial with this
approach since I have the app and a copy of the server files on my
development machine. Security is in place requiring user names to log into
the application and a limit on the number of users.

Your help has been very specific, very prompt and very educational. I have
very little Access experience and some of the nuances of the product on
which you have given counsel will prove most helpful.

I indeed do hope I can be more active in the microsoft.public.????
newsgroups. I didn't realize what a resource they were until this past
week(end).

Be well. I'm going to give your approach a test in my environment.

Justice

 

[david epsom dot com dot au]

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)

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.

 

[Albert D. Kallal]

Thanks so much for your help. I should be able to attempt a trial with
this approach since I have the app and a copy of the server files on my
development machine. Security is in place requiring user names to log
into the application and a limit on the number of users.

If you need an example word merge to word templates, I have a working system
that might be of help
for you.

You might even dump the old system..and temporary use my template merge
system. It works with a2003.

You an find a working copy here (it even has some sample data to "test"
with):

http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html

 

[ITJRW]

I'm sure that would be helpful, Albert. I've already downloaded it and many
of the resources you've linked me to. Thanks alot.

Justice

 

[ITJRW]

I'm sure not worried about the long message. Your response is very
comprehensive and very helpful. I did verify that many, if not all, of the
files that did not copy are there already and are newer versions.

The .dat file that is being successfully created is a tab delimited text
file.

Thanks much for the three lines of code.

The app is currently configured to send the .dat file to the location of the
master merge files which is of the form f:\appname\letters\ with the f:\
being a mapped network drive. There are no long names in the pathing but
quite a few of the documents are long named (> 8.doc). You're the first one
to respond to the error messages that are generated.

I'll test the registry change right away on my development machine.

This is the first time I've really used the microsoft.public.??? newsgroups.
I'm extremely impressed with the responses I've received. Thanks for making
yourself available. Hopefully, I'll be able to help some others. Do you
just get on the newsgroup and search for things you can offer help on and
then read all the answers already provided? If so, you all are very noble
persons..

Justice

 

[ITJRW]

David,

I made the registry change and it didn't change the actions of the app or
Word. I changed them back. Both times, I rebooted, of course.

One of the things I had not tested are two other options that the
application has relative to the merge. Once a form number is selected,
there are radio button options in an options box: Merge, Edit Document, and
Edit Form.

Strangely enough the Merge does the merge. I still get the Merge Error
(Word), #1056 (0) box indicating "This is not a valid file name. Try one or
more of the following: "Check the path to make sure it was typed correctly.
*Select a file from the list of files and folders" (which I don't have the
opportunity to do).

Also the Edit form option opens Word with the master merge document ready
for editing but without a data source ready for editing the document. If I
click on the Open Data Source Merge Menu icon and enter the path to the
BaseCase.dat file in the Data Source window, I have the field ready for
insertion into the document as expected. The BaseCase.dat file is the
"empty" header containing field names only file which is used for their
document creation.

It is only the Edit document option that won't open Word with the proper
merged document, the data source .dat file is created properly and obviously
the calls to Word and to the master merge document files doesn't seem to be
a problem.

If the users did not often have to do some tweaking of the merged documents,
they could just print them out.

Any other ideas? You've moved me along a bit. Thanks.

Justice

I installed VS 6.0, compiled the program you suggested and named it
WinWord.exe after naming the _real_ WinWord.exe WinWord_real.exe.

The result of calling this "WinWord.exe" was: "/Automation -Embedding"

I don't have an old version of Word installed. Is this a command line
argument being passed to Word? What does it do?

I get some new error messages.

 

[david epsom dot com dot au]

/I/ just get on the newsgroup and look for questions that are interesting.
After I answer, I frequently see earlier and better answers which hadn't
arrived here yet, and I get to compare my ideas with those suggested by
other people. Sometimes, I even get corrected, if I've posted something
both technical and wrong :~) (Easy mistakes don't merit a correction:
I have to read the other replies to see what other people think.)
Either way, the exercise of suggesting a solution helps me be prepared
for similar questions in my day job, and the occasional response gives
me a better idea of what works and what doesn't :~).

But if you look around, you will see that there are also people here who
'answer the boring repetitive questions': they aren't all as self-indulgent
as I am!

(david)

 

[ITJRW]

I really appreciate the assistance. This problem I'm having is a challenge.
I should probably just go on and develop my replacement app, but this thing
just does not make sense to me and I want to know more of why and what in
case I face it again in the future.

Please see my next post with updated information if you feel up to more
brain burn.

Thanks again.

Justice

 

[Peter Gillett]

I'm sure not worried about the long message. Your response is very
comprehensive and very helpful. I did verify that many, if not all, of the
files that did not copy are there already and are newer versions.

The .dat file that is being successfully created is a tab delimited text
file.

Thanks much for the three lines of code.

The app is currently configured to send the .dat file to the location of the
master merge files which is of the form f:\appname\letters\ with the f:\
being a mapped network drive. There are no long names in the pathing but
quite a few of the documents are long named (> 8.doc). You're the first one
to respond to the error messages that are generated.

I notice above that you say that the .dat file is on a mapped network
drive. Is there any chance of timing problems?
It might be worth trying with the file on a local drive.

Peter


[SNIP]

 

[ITJRW]

I don't think so. The mapped drive I'm testing with is actually one on my
own development machine done to emulate the users in the client server
situation. Same result on both.

I've done some testing with Filemon and Regmon and it appears that the
legacy app is having trouble with the long file names of the files. I'm
going to test some more with the files that have 8.3 standard naming
tomorrow.

Thanks for the input.

I'm sure not worried about the long message. Your response is very
comprehensive and very helpful. I did verify that many, if not all, of
the
files that did not copy are there already and are newer versions.

The .dat file that is being successfully created is a tab delimited text
file.

Thanks much for the three lines of code.

The app is currently configured to send the .dat file to the location of
the
master merge files which is of the form f:\appname\letters\ with the f:\
being a mapped network drive. There are no long names in the pathing but
quite a few of the documents are long named (> 8.doc). You're the first
one
to respond to the error messages that are generated.

I notice above that you say that the .dat file is on a mapped network
drive. Is there any chance of timing problems?
It might be worth trying with the file on a local drive.

Peter


[SNIP]