Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
DiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWord
DirectoryUser Groups
Related Topics
Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ...

MS Office Forum / Word / Mailmerge and Fax / March 2007

Tip: Looking for answers? Try searching our database.

Word 2003 was unable to open the data source file has no extension

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Derrick Smith - 01 Mar 2007 14:52 GMT
Hello,
Our custom access database creates a merge file called "doc merge data" on
users' pcs. This file has no extension.
With Word 2000 or below the merge opens with a full merge toolbar.

With Word 2003 it greys the toolbar out, and using the merge wizard the file
returns "Word was unable to open the data source."
I have ticked the confirm conversion at open option as suggested. If I
rename the file so it has a .txt extension all works. I've read previous
forum posts and all involve an extension on the file.

Other than re-writing the access database, there must be another difference
between Word versions if the file is okay in previous...
Any ideas?
Many thanks
Peter Jamieson - 01 Mar 2007 15:14 GMT
Word seems to connect to an extensionless Word document when I connect
/manually/ here. I suggest you create the registry item described in the
following article, even though the title may not appear relevant:

http://support.microsoft.com/kb/825765

Peter Jamieson

> Hello,
> Our custom access database creates a merge file called "doc merge data" on
[quoted text clipped - 13 lines]
> Any ideas?
> Many thanks
Graham Mayor - 01 Mar 2007 15:36 GMT
It doesn't work for me (whether the text file is comma or tab delimited) and
I already have that registry entry.?

Signature

<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor -  Word MVP

My web site www.gmayor.com
Word MVP web site http://word.mvps.org
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>

> Word seems to connect to an extensionless Word document when I connect
> /manually/ here. I suggest you create the registry item described in
[quoted text clipped - 21 lines]
>> Any ideas?
>> Many thanks
Peter Jamieson - 01 Mar 2007 16:58 GMT
Yes, I was wrongly looking at a .doc format file.

I would agree that having the applicition provide a .txt extension is a much
better idea.

However, if that is not possible, try
a. check Word Tools|Options|General|"Confirm conversions at open"
b. connect to the text file
c. in Confirm Data Source, check "Show All"
d. Select Text files (*.txt)
e. if the connection succeeds, save the mail merge main document
f. re-open (manually or programmatically)

There may still be problems if
a. Word thinks it needs to pop up its character encoding dialog or
b. the connection is made programmatically, in whcih case it may be
necessary to provide a Subtype parameter in OpenDataSource

Some background...

While it's true that Word's converters are associated with extensions, the
extensions are primarily used by Word to determine which converters to ask
for a conversion service. Word can ask a converter to try to perform a
conversion regardless of the extension. The first thing the converter does
is to decide whether or not it can convert the file Word is asking about -
in some cases converters may refuse on the grounds that the extension is
wrong but I suspect most of them actually examine some or all of the content
and base their decision on that.

The ODBC and OLEDB methods don't use "Word text converters" and the
association between an ODBC driver or OLEDB provider and an extension is
even hazier. For example, I don't think anything in Windows actually says
"for this file type, use this OLE DB provider" even though some MS
documentation suggests that that is what happens. For ODBC, there is
typically some extension information in the Driver's descriptive name for
those drivers that work with files rather than servers such as SQL Server,
and it's possible that Word looks at those. Otherwise, I suspect Word always
presents OLEDB as an option, then probably tries to use the Jet OLEDB
provider if you choose the OLEDB option. In that case, there is a set of
file extensions that Word or the provider can try to use to determine the
correct "Engine Type". Unfortunately in the case of the Jet "Text Engine",
there really does not seem to be a way to tell OLE DB that an extensionless
file in the specified folder is a "table" in the text "database" specified
by the folder name.

Peter Jamieson

> It doesn't work for me (whether the text file is comma or tab delimited)
> and I already have that registry entry.?
[quoted text clipped - 24 lines]
>>> Any ideas?
>>> Many thanks
Graham Mayor - 01 Mar 2007 15:20 GMT
What you are experiencing is normal. behaviour with Word 2003. It is all to
do with the way Word 2003 attaches merge to its data. Without the extension,
there is insufficient information in a text file for Word to determine the
type of converter required. You can see this by renaming to *.txt and note
the extra conversion options that you get when manually attaching the data.

Change the database to produce an output with a TXT extension.

Signature

<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor -  Word MVP

My web site www.gmayor.com
Word MVP web site http://word.mvps.org
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>

> Hello,
> Our custom access database creates a merge file called "doc merge
[quoted text clipped - 11 lines]
> Any ideas?
> Many thanks
Derrick Smith - 01 Mar 2007 16:54 GMT
Thanks folks, the reg setting did work for me, the merge bar is live and all
data is read.
Cheers for the help.

> What you are experiencing is normal. behaviour with Word 2003. It is all to
> do with the way Word 2003 attaches merge to its data. Without the extension,
[quoted text clipped - 19 lines]
> > Any ideas?
> > Many thanks
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.