I can just about see circumstances in which this might occur, but the case
isn't particularly convincing, which suggests that the explanation is likely
to be staring us in the face
I gather you're working at a distance from
the problem so it may be difficult to check stuff and experiment.
It seems to me that whatever may be in the Access file or intermediate file,
Word will only compare correctly with "0" if the YesNo value /it reads/ is
"0", and will only compare correctly with "False" if the values it actually
sees are "False" and "True". Which isn't what you actually say, but I wonder
whether that is actually the case.
As far as I know, if Word is getting its data from a text file, the only way
it would see -1 as "True" is if
a. it's opening the file using OLE DB (i.e. it's Word 2002 or later)
b. there's a SCHEMA.INI file in the same folder as the text file that
specifies that the column has type "Bit". This could well be the case
because when you export from Access, Access does create such entries in a
SCHEMA.INI - at least sometimes. If someone is using an Access module or
macro to export, then it may also specify a particular export layout.
However, the hypothesis also has to explain why you see -1/0 when you have a
data source with 1 record, but True/False when it has many records.
Possibilities include
a. Word is opening the file using OLE DB but only recognises that the
column is "Yes/No" type (and provides True/False instead of -1/0 when there
are more than so many records in the file - perhaps 8 or 25. I don't see
this here.
b. Access sets up a SCHEMA.INI entry when it exports multiple records, but
not a single record. (In fact, Access itself does not appear to make this
distinction, although if the export is being done through code, perhaps
something else is doing something differently. What I see is bizarre: when
you export manually, if you specify a file extension (e.g. .txt) Access just
exports the data and modifes SCHEMA.INI. If you do not, Access takes you
through the export layout dialog and /does not/ modify SCHEMA.INI)
c. Word tries to connect to the one-row data files using OLE DB (the
defaul) but fails and falls back to using its Text converter. With the
multi-row files, it succeeds. This is an unlikely way around.
Even if the right explanation is in there somewhere, there's the question of
what you do about it and how to find out exactly what's going. What I would
probably prefer to do is avoid the problem altoggether by trying to export
the data using the string values "Y" and "N" instead of numeric/boolean
values. If I had to determine connection method etc., I'd probably use Word
VBA to find the values of ActiveDocument.MailMerge.DataSource.COnnectString,
..QueryString and .Type /after/ the connection had been made.
Best I can right now...
Peter Jamieson