Re: Data source not "sticking"

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Sat, 20 Jun 2009 16:59:57 -0400, Kenneth
<usenet@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

On Fri, 19 Jun 2009 16:54:01 -0400, Kenneth
<usenet@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

On Fri, 19 Jun 2009 12:02:08 +0100, "Peter Jamieson"
<pjj@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

I have been looking around, but there are a lot of possibilities to test,
and things look different even since the last time I looked.

First, as far as I am aware, when the data source is a text file and you
have to specify the encoding, Word does not store the information about the
encoding when it saves the mail merge main document. Therefore, you will
always be prompted for the encoding /if/ Word has reason to believe that the
text file is not using the default encoding specified on your system
(typically, when you installed Windows) or the encoding specified in a
defaultCPG entry in the registry (although that entry is not documented for
use with Word 2007, it does seem to work). From a dev. perspective, to be
sure that users would not see this dialog I think you would have to be in a
position to specify DefaultCPG in a standard way for all users, specify it
as something that can cope with "everything", (e.g. UTF-8), and generate all
your text files to conform to that standard. (No, I haven't tried it).

Alternatives - other than might be
a. to generate a different type of file whose encoding is "built in". The
only formats likely to do that for you would be Word formats. To generate
them directly, you'd probably have to write .rtf or WordProcessing/Word2007
XML format (i.e. not the sort of simple XML format doucment you might
produce by exporting from Access, but a complete Word document with the data
in delimited or tabular format, built using WordProcessingML or Word2007
XML. Frankly, I wouldn't wish either of those two options on anyone. But you
could also consider
- saving as text in a known encoding such as UTF8
- then opening the file in Word using Automation - in that case you should
be able to specify "encoded text" and UTF8 as the encoding.
Or you could even automate Word and create a document (say, containing a
table) with your data.

b. to use a different method to open the text file that wold recognise the
encoding. Unfortunately, that is also fraught with difficulty. The only way
I know how to do it is to create a .odc file, and ensure that the text file
is listed in a schema.ini file in the same folder as the text file, with the
delimiter character and encoding specified. There are a cople of wys to do
that, but you will find for example that the number of fields is limited to
255/256, stuff such as multiline fields may not work, etc. etc.

(Not sure this is relevant since you are I think using old-style .dots,
but...

Finally, not long ago I had a look at the XML that Word generates when it
saves a mail merge main document in a Word 2007 format. Word can store the
data source info in more than one way, and in some cases you seem to get the
problem with the data source not reconnecting. I haven't got to the bottom
of this yet (and may never do so), but in general things seem to go better
when Word defines a "relationship" element that specifies the data source
file name. Curiously, when connecting with text files via OLE DB, Word
maintains two lots of XML data about the connection ("odso" data (ODSO is
the Office Data Source object used to open many types of data source), and
non-"odso" data). In both cases all the data points to temp files, not the
original file, whose details are stored (twice) in relationship elements. In
the case where the data source /was/ an ODBC data source in an older version
of Word, if you "save as" one of these formats, you may end up with no
relationship element and no other source file information except the info.
embedded in the connection string and SQL query string. Word really doesn't
seem to like that.

)

Peter Jamieson

Hi Peter,

I appreciate your detailed suggestions...

I strongly suspect that something has changed in my Word
installation, though at the moments, I have no idea what
that might be.

Right now, I'm working on this from "the other end" that is,
from the database side.

It may be possible that there is a driver that would allow
my database to create TXT files that are UTF-8. If so, that
would be an easy next step.

Right now, the TXT files that I create are 'ascii' ANSI.
And, they open properly in Notepad in that they display
accented characters properly.

A few years ago, I had some sort of difficulty with accented
characters (again, printing with Word macros) and I was
advised to use the 'ascii' ANSI language driver. When I used
it, all my problems vanished (Well, not ALL, but at least
those related to printing...)

Until about a week ago, Word was happy with these TXT files,
but now, with no (intended) modification, Word doesn't like
the TXT files, and it is also losing the datasource
associations for files on the lan. Both of these worked
smoothly with no user intervention...

This is a strange one, but I should have my current question
about a new driver for the TXT files answered shortly.

I'll be back when I learn more,

Hi again Peter,

I have experimented further, and have learned a bit more.

First, my database cannot produce TXT files that are UTF-8
compatible.

The closest I can come is apparently what Paradox calls
'ascii' ANSI, and, until recently, that has worked just fine
in partnership with Word.

Now, as I have explained, the Word File Conversion dialog
opens, and when it does, it is set to Japanese-JIS. If I
manually reset it to Windows(Default) all looks fine.

Next, I thought to rework the Word macro that I use to do
the printing. I know close to nothing about the Word
programming language but always was able to create the
macros I need by recording, and tweaking the result.

I tried to record a new macro including my setting the File
Conversion choice to Windows (Default) but apparently, that
setting would not be recorded.

So, as of now, I am stuck.

What might you suggest as my next step?

Many thanks, as before,

Hi again,

Some more information that I neglected to include:

The Japanese conversion should have been "Japanese
Shift-JIS" in my previous post.

Next, the particular character I am having trouble with is
Alt-0233, an acute accented lower case e.

Also, when I am in the Word File Conversion dialog, and
choose UTF-8 the accented e does not appear properly: The
accented e simply vanishes (and it is not replaced with a
space.)

When I choose UTF-7, the text looks as it should with the
accented e.

Of course, it would appear that all this could be resolved
if I could find a way to tell Word to always use the Windows
(Default) to convert a TXT file (whether with a setting
somewhere, or with code in the macros.)

As before, thanks for any further help,
--
Kenneth

If you email... Please remove the "SPAMLESS."
.

Relevant Pages

  • Re: Data source not "sticking"
    ... First, as far as I am aware, when the data source is a text file and you have to specify the encoding, Word does not store the information about the encoding when it saves the mail merge main document. ... To generate them directly, you'd probably have to write .rtf or WordProcessing/Word2007 XML format (i.e. not the sort of simple XML format doucment you might produce by exporting from Access, but a complete Word document with the data in delimited or tabular format, built using WordProcessingML or Word2007 XML. ...
    (microsoft.public.word.docmanagement)
  • Re: Word Mail Merge Date Format
    ... up and saves it out to an excel document - which is used as input to ... another look, but on the business of connecting to text files, recently I started having a more thorough look at this and discovered that by using a ..odc file to specify the data source, you can also get the OLE DB provider to look at the SCHEMA.INI file containing information - including character encoding - about specified text files. ... One bit of information that isn't in that message is that the SCHEMA.INI lets you specify a date format. ...
    (microsoft.public.word.mailmerge.fields)
  • Re: Data source not "sticking"
    ... First, as far as I am aware, when the data source is a text file and you ... have to specify the encoding, Word does not store the information about the ... encoding when it saves the mail merge main document. ... XML format (i.e. not the sort of simple XML format doucment you might ...
    (microsoft.public.word.docmanagement)
  • Re: Data source not "sticking"
    ... First, as far as I am aware, when the data source is a text file and you ... have to specify the encoding, Word does not store the information about the ... encoding when it saves the mail merge main document. ... XML format (i.e. not the sort of simple XML format doucment you might ...
    (microsoft.public.word.docmanagement)
  • Re: How do I tell Word 2003 my mail-merge text is NOT UTF-8?
    ... (It's also possible that opening the document in Word with an explicit encoding, saving it as a WOrd document, then using that as the data source for a merge, as described in that article, might do the trick). ... If you are using Word 2000, that can't work because it doesn't support OLE DB and .odc files. ... Although you can use ODBC to connect using a similar SCHEMA.INI, the ODBC driver does not seem to recognise all the entries in the .INI file that the OLE DB provider does, and it doesn't have the same character encoding support anyway AFAIK. ...
    (microsoft.public.word.mailmerge.fields)