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.

It has been suggested that I write a dummy application in VB6 to impersonate
Word 6 and receive the file names passed and then use those and call Word 11
from this dummy app, passing the merge file and data source file names to
Word 11 on startup. I don't know how I'd go about "impersonating Word 6"
and create this "DDE sink" that's been suggested.

Any suggestions for any approach 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