Too Many Data Fields in Mail Merge

[Lynda]

I am working in Word 2003 mail merge and using a .csv data file as the data
source file. The CSV file has the field headings as a header. Lately,
every time I try to merge from the .CSV data file to the merge letter, I get
the message "Too Many Data Fields." I then have to click 'ok' to contunue.
A few letters will merge ok and then this message pops up again. Is there
some setting that needs to be set for prevent this from occurring?

Any suggestions would be appreciated.

Lynda

 

[Peter Jamieson]

Do you have any data that contains commas (assuming that your CSV data
really is comma-delimite rather than delimited by some other character)? If
so, is it enclosed in double-quotes?

When you select the mail merge data source, does Word ask you about the
field delimiter? Does it also ask yu about the "record delimiter"? (Word has
a number of ways it can open a CSV data source and I'm trying to establish
which one it is using).

Peter Jamieson

 

[Lynda]

Hi Peter:

The CSV data file is comma-delimited with double-quotes.

The data file has first a header with the field names separated by a comma.
The actual data fields are enclosed in double quotes and each data element
is separated by a comma as well.

In some cases, the Word does ask about the field delimiter and record
delimiter. This does not happen with all of our mail merge letters --only a
couple even though all letters are constructed in the same way using the
same type of data source.

We are baffled why this is happening with some letters but not with others.

 

[Graham Mayor]

The same *type* of data source or the same data source?

The probability is that you have an extra unwanted comma in one or more of
the records which makes the record(s) appear to have more fields than the
header suggests.

 

[Peter Jamieson]

We are baffled why this is happening with some letters but not with

others.

So am I But at the moment I can only think of two things to do:
a. ask a few more questions and see if they lead anywhere useful
b. suggest a way to change the way Word gets the data. It might not fix the
problem, but it could shed some more light on what's happening.

Some more questions:
c. do you have any double quotes in your data (I mean, other than the ones
used to enclose your data fields) ?
d. do your data sources have small numbers of columns? Lots of columns? A
lot of variation? Any with over 255 columns? Or do you have very long
records in some data sources, i.e. in terms of the number of characters in
the line.
e. are your data sources created in different ways or all in the same way
(e.g. export from a database server) ?

If you don't have any problems such as (c) and you have 255 columns or
fewer, you can try the approach described in the message at

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

If you can't find that, try searching Google Groups for jamieson SCHEMA.INI
odc Unicode

Peter Jamieson

 

[Lynda]

Hi and thanks for attempting to solve this problem.
:

a. ask a few more questions and see if they lead anywhere useful
b. suggest a way to change the way Word gets the data. It might not fix
the problem, but it could shed some more light on what's happening.

Some more questions:
c. do you have any double quotes in your data (I mean, other than the ones
used to enclose your data fields) ?

No, the double quotes just enclose the data fields

d. do your data sources have small numbers of columns? Lots of columns? A
lot of variation? Any with over 255 columns? Or do you have very long
records in some data sources, i.e. in terms of the number of characters in
the line.

Our data source comes out of a Letter Generation tool in PeopleSoft database
and has a large number of fields.

e. are your data sources created in different ways or all in the same way

They are all created exactly the same way. They are generated out of our
enterprise database via LetterGen.

(e.g. export from a database server) ?

We have more than 255 columns--perhaps that is the problem. If I had any
control out of the delivery of the CSV file, I would try to use some other
mechanism, but this is all built into the enterprise database.

Thanks for your help. I will keep looking for solutions

If you don't have any problems such as (c) and you have 255 columns or
fewer, you can try the approach described in the message at

http://groups.google.com/group/micr....INI+odc+text+unicode&rnum=1#d39588c43fc31d70>> If you can't find that, try searching Google Groups for jamiesonSCHEMA.INI odc Unicode>> Peter Jamieson>> "Lynda" <lynda@maine.edu> wrote in messageHi Peter:>>>> The CSV data file is comma-delimited with double-quotes.>>>> The data file has first a header with the field names separated by acomma. The actual data fields are enclosed in double quotes and each dataelement is separated by a comma as well.>>>> In some cases, the Word does ask about the field delimiter and recorddelimiter. This does not happen with all of our mail merge letters --only acouple even though all letters are constructed in the same way using thesame type of data source.>>>> We are baffled why this is happening with some letters but not withothers.>>>>>> "Peter Jamieson" <pjj@KillmapSpjjnet.demon.co.uk> wrote in messageDo you have any data that contains commas (assuming that your CSV datareally is comma-delimite rather than delimited by some other character)? Ifso, is it enclosed in double-quotes?>>>>>> When you select the mail merge data source, does Word ask you about thefield delimiter? Does it also ask yu about the "record delimiter"? (Word hasa number of ways it can open a CSV data source and I'm trying to establishwhich one it is using).>>>>>> Peter Jamieson>>>>>> "Lynda" <lynda@maine.edu> wrote in messageam working in Word 2003 mail merge and using a .csv data file as thedata source file. The CSV file has the field headings as a header. Lately,every time I try to merge from the .CSV data file to the merge letter, I getthe message "Too Many Data Fields." I then have to click 'ok' to contunue.A few letters will merge ok and then this message pops up again. Is theresome setting that needs to be set for prevent this from occurring?>>>>>>>> Any suggestions would be appreciated.>>>>>>>> Lynda>>>>>>>>>>>>

 

[Peter Jamieson]

I can't think of any more really obvious possibilities, but...

Word always has to use its "text converter" connection method to open the
data source if it has more than 255 columns, and that's what pops up the box
asking for the two delimiter characters.

If we go back to your original question, do some of the merge documents
cause the delimiter prompts and others avoid it, even with exactly the same
data source? Or are they data sources with the same field names but
different data?

Do you use these merges on different machines, and if so, does each merge
behave the same way no matter which machine it's running on?

Peter Jamieson

 

[Graham Mayor]

If it is a comma delimited file, open it in Excel. If there are any
anomalies in the data they should be more obvious there. You could always
use the Excel file as your data source?

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


<>>< ><<> ><<> <>>< ><<> <>>< <>><<>

 

[Lynda]

Hi Peter:

The data file always comes from the same source, but the data may be
different. The data comes from a process in PeopleSoft that generates the
file. We then save that file as a CSV file.

All of our letters use a CSV file as its data source. There are more fields
than ExCel likes that is why the CSV file.

Multiple users may merge the CSV files to letters, but all of the letters
and CSV files exist on a common shared drive.

One or two letters do prompt for the delimiter, and record separator.

Oddly, we did not experience this as a problem until about a month ago. We
are all on the same version of Word, but do have different machines.

Hope that helps.

Lynda

 

[Peter Jamieson]

Hi Lynda,

It's just possible that the reason why the dialog is displayed sometimes and
not others is simply because the data varies. Word does have to work quite
hard to guess what the delimiters might be, even when it's usually as plain
as day to a human being. (One of the problems it has is that Word does not
assume that you are using a particular character encoding for your file - as
the data gets more complicated it may guess wrongly, and as far as I know
there is no simple way to tell Word to assume the same encoding every time).
However, the key factor here seems much more likely to be an automated
update applied around a month ago, as you obviously suspect.

It's dificult to know how to proceed in this situation. I think I would
either contact Microsoft Technical Support (we are just volunteers here),
create an incident (precisely how to do that depends on whether you have an
agreement with them, and of course they have all sorts of rules about
charging v. free incidents), and take it from there. Or, if you are able to
restore to previous versions, take one machine back in time and see if you
can identify which change seems to have introduced the problem. But even
then there is little option but to contact Technical Support to have a
resolution unless you can exclude the specific update that creates the
problem.

If you happen to have a copy of Excel 2007 around, I would try Graham's idea
of opening the .csv in Excel and seeing what happens, because the 2007
version does support far more columns (and I have just verified that you can
open and save .csv files with more than 255 columns in that version.
However, even if you had any intention of doing so, moving to Office 2007
would not currently be a solution to your merge problem, because there is
still no way to get more than 255 columns from Excel 2007 in a merge.

Sorry I couldn't find a way through, but if you do find a solution via
Technical Support it would be appreciated if you could post back.

Peter Jamieson