Limit on number of mail merge fields in Word 2007/XP

[geoffsb]

Hi

Can someone out there tell me what the limit on mail merge fields is for the
above versions of Word e.g. 2007 and XP?

I'm currently trying to import data into a mail merge template using a Word
table as my data source in Word 2003, and am hitting the "Maximum number of
fields exceeded" error (there are 71 fields in the table). Is the maximum
number allowed any higher in XP or 2007 when using a Word table as a data
source?

Thanks

Geoff

 

[Peter Jamieson]

That's interesting - I thought the maximum no. of columns in a Word table
was 63, and that has not changed in Word 2007. Maybe you are talking about a
different kind of table?

If you use a delimited format (e.g. comma-limited) format in Word you should
be able to exceed that limit - for example, I just created a Word XP
document with 2000 "columns" and 10 rows, was able to use it as a data
source, was able to pick any of the 2000 fields from the insert merge field
dropdown, but
a. Word can be very slow when reading Word-format data sources, and the
larger the slower, generally speaking.
b. the Edit Recipients dialog box starts running into problems with large
amounts of data - in this case, in Word XP, it stopped displaying column
names at around 380 columns.

It's roughly the same story in Word 2007 AFAICS.

Some of these limits may be related to things other than the counts or rows
and columns, e.g. the total number of characters in the field names, or in
the field values, or both. Also, e.g., I have experienced problems in the
past when the line length of a line in Word exceeds around 1500 characters.

 

[geoffsb]

Hi Peter

Thanks for this response - to shed some more light on what I'm doing, I'm
exporting data from Oracle applications via a plug-in which exports the
relevant data to a Word document in Word table format, which is then merged
with a template document to produce the final mail merged document. I don't
know if the format can be changed (will try to confirm this with Oracle) but
I suspect not!

Regards

Geoff

 

[Peter Jamieson]

relevant data to a Word document in Word table format, which is then

merged

1. It may be worth asking them precisely how it is doing that - e.g. is it,
or is it capable of
- automating Word (probably)
- generating .rtf format, or possibly even .doc binary format
- generating HTML table format, in which case there may be another way to
exceed that 63 column limit
- generating some other format such as .docx (same problems), non-Word
formats, etc. etc.

The /nice/ thing about Word table format is that it makes problems with
delimiters such as ",", """ etc. go away.

2. Are you in a position to use an Oracle View or Table directly as the data
source for your merge? (FWIW I always found this difficult to set up with
Oracle's ODBC driver/OLE DB provider and the Microsoft-provided ones only
support Oracle features up to about v.6. It's a while since I had a copy of
Oracle here, too

 

[geoffsb]

Hi Peter

I've done a bit of investigate work into how it does what it does - there's
some VB code which gets generated the moment the export process is kicked off
which basically performs the merge. Short of editing the generated code every
time the export occurs however (not feasible!) we'd have to get Oracle
involved to change the generated VB code which means hiring one of their
consultants for x pounds a day :-(

I suppose one question to ask is, can VB for Word be coded in such a way to
produce an HTML table or other format as you suggest below? If so, this could
potentially be an avenue worth exploring.

In answer to your other question, the data is being supplied by a view so it
might be possible to connect to that directly but this again makes the final
solution more complex and less user-friendly which is one of the primary
requirements for this project! Again, we might have to get the consultants in
to determine just what is or isn't possible.

Geoff

 

[Peter Jamieson]

Some of that sounds curiously familiar - you don't happen to work for Kent
Fire Brigade by any chance?

But in essence, there's no wriggle room in the process that kicks off the
merge.

I suppose one question to ask is, can VB for Word be coded in such a way
to
produce an HTML table or other format as you suggest below? If so, this
could
potentially be an avenue worth exploring.

This is all rather speculative as I don't know exactly what their code does,
but...
a. if they are using the Word object model to create a Word document for
use as a data source, the simplest /type/ of change they could probably make
would be to generate a Word document with a different internal format -
that's regardless of whether they are using Word VBA, or the "full" VB,
VBScript or some other application's VBA, as long as it's capable of driving
the Word object model.
b. if they are currently generating a Word table, the simplest change is
likely to be to generate a Word document with "delimited text", e.g.

columnname1,columnname2,columnname3
row1value1,row1value2,row1value3
row2value1,row2value2,row2value3

To do that safely they would have to ensure that columns that might contain
delimiter characters (in this case double-quote, comma and CR or CRLF) were
probably wrapped up, typically by wrapping them in double-quotes and
doubling up any double-quotes inside the values.

However, with VB/VBA you can create any type of plain text file you want.
You would just have to work at it a bit harder, i.e. the code would look
somewhat different. You could also (for example) create a Jet/Access
database "on-the-fly" (you don't need Access either to create it or use it),
or an Excel workbook "on-the-fly". In each case you need to know that the
machine on which the code actually runs has the necessary "MDAC" objects and
you might have to set up a couple of other things.

In answer to your other question, the data is being supplied by a view so
it
might be possible to connect to that directly but this again makes the
final
solution more complex and less user-friendly which is one of the primary
requirements for this project!

Well, I know what you mean but I'm not convinced that it would necessarily
make things more complicated /for the end user/, because it would typically
be possible to set the connectin up in the document, or have a very small
amount of Word VBA to set it up. But again, tthe conditions have to be
correct on the end user system - for example, you may have to deal with the
problem described in http://support.microsoft.com/kb/825765/en-us, and that
requires a registry change - if it's justy one machine, perhaps no oproblem;
if on thousands there may be difficulties. And it's not the sort of thing
that's simple to investigate without being in front of one of the machines
in question.

 

[jim newman]

To do that safely they would have to ensure that columns that might contain
delimiter characters (in this case double-quote, comma and CR or CRLF) were
probably wrapped up, typically by wrapping them in double-quotes and
doubling up any double-quotes inside the values.



THANK YOU!!!!