Word Mail Merge Date Format

[merecat_]

I'm using Word 2002 SP2.

Have had some real problems over the last week trying to get Word's
mail merge to correctly (and consistently) interpret date values.

I tried feeding in all sorts of date formats - this didn't work.

I tried forcing Word to interpret my date as a string - this didn't
work either.

I was about to resort to injecting my date as three separate fields (a
real sledgehammer to crack a nut - that's how desperate I was).

But then I tried enclosing my date in '#' characters - and it worked -
I recall date literals being encoded like this in MS Access.

E.g. the dates in my text file were thus:

#12 december 2002#

I can then us the /@ "dd MMM yyyy" type merge field switches to format
the date as I wish in Word.

Couldn't find this answer anywhere on the net - so thought I'd post it
here in case it helps others. I have no idea whether this works on
other versions of Word or indeed whether the same problem occurs.

It's just so confusing and there is no clear documentation for this.
Why o why does the world use software that is so badly documented!!

BTW I should point out - my data resides in a unicode text file (tab
delimited) but my 'pre-processing' takes this text file and opens it
up and saves it out to an excel document - which is used as input to
the mail merge process. I couldn't get Word to accept my text file
directly (perhaps this was part of the original problem - i.e.
translating the text file into Excel - to be honest I don't really
care [I've been ground down by the problem as you see!] - it works now
anyway - yahoo!).

Mark.
UK.

 

[Peter Jamieson]

Hi Mark,

Thanks for posting. There's an article at

http://support.microsoft.com/kb/327579/en-us

which covers one important aspect of this issue (however, I am not
completely sure that the problem was permanently fixed in SP3 or in later
versions of Word).

BTW I should point out - my data resides in a unicode text file (tab
delimited) but my 'pre-processing' takes this text file and opens it
up and saves it out to an excel document - which is used as input to
the mail merge process. I couldn't get Word to accept my text file
directly (perhaps this was part of the original problem - i.e.
translating the text file into Excel - to be honest I don't really
care [I've been ground down by the problem as you see!]

You are not the only one You may well be too ground down to have
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. You may be able to find the relevant
message at

http://groups.google.com/group/micr....INI+odc+text+unicode&rnum=1#d39588c43fc31d70

otherwise, try searching Google Groups for jamieson SCHEMA.INI odc Unicode

One bit of information that isn't in that message is that the SCHEMA.INI
lets you specify a date format. However, I don't know whether the OLE DB
provider still gets it wrong.

Peter Jamieson

I'm using Word 2002 SP2.

Have had some real problems over the last week trying to get Word's
mail merge to correctly (and consistently) interpret date values.

I tried feeding in all sorts of date formats - this didn't work.

I tried forcing Word to interpret my date as a string - this didn't
work either.

I was about to resort to injecting my date as three separate fields (a
real sledgehammer to crack a nut - that's how desperate I was).

But then I tried enclosing my date in '#' characters - and it worked -
I recall date literals being encoded like this in MS Access.

E.g. the dates in my text file were thus:

#12 december 2002#

I can then us the /@ "dd MMM yyyy" type merge field switches to format
the date as I wish in Word.

Couldn't find this answer anywhere on the net - so thought I'd post it
here in case it helps others. I have no idea whether this works on
other versions of Word or indeed whether the same problem occurs.

It's just so confusing and there is no clear documentation for this.
Why o why does the world use software that is so badly documented!!

BTW I should point out - my data resides in a unicode text file (tab
delimited) but my 'pre-processing' takes this text file and opens it
up and saves it out to an excel document - which is used as input to
the mail merge process. I couldn't get Word to accept my text file
directly (perhaps this was part of the original problem - i.e.
translating the text file into Excel - to be honest I don't really
care [I've been ground down by the problem as you see!] - it works now
anyway - yahoo!).

Mark.
UK.

 

[merecat_]

Hi Peter,

This fix would be fine if we were able to move off of SP2 - but we are
not!

Regards,
Mark.

 

[Peter Jamieson]

This fix would be fine if we were able to move off of SP2 - but we are

not!

I suppose the chances are that you would not be able to install the hotfix
mentioned there either?

Peter Jamieson

 

[merecat_]

Hi Peter,

Oh! I had missed the hot fix, and the schema.ini too!!

Apologies.

Our desktops here are all locked down, we don't have installation
rights to change the core software build (of which Office is part).
Software like this is controlled by a central service too and
'floated' onto client machines over the network.

However the schema.ini route does sound interesting and one which
would be feasible in my case (as it just involves some configuration
files by the sounds of it), and one I would certainly explore if my
current 'hash character' fix goes pear-shaped or if I have the same
problem to solve in future. It sounds like the right way to do it if I
were starting from scratch again.

Regards,
Mark.

 

[Peter Jamieson]

Our desktops here are all locked down, we don't have installation

rights to change the core software build (of which Office is part).
Software like this is controlled by a central service too and
'floated' onto client machines over the network.

Yes, I suspected it would be like that.

I don't know if the schema.ini thing will fix this prticular problem since
the same OLE DB provider is involved, but maybe the fact that it's using a
different IISAM will make a difference. Not sure I will ever ge around to
trying that...

Peter Jamieson