Yes, that's also an option, quite probably in this case. If the user is
trying to deduplicate then it requires that the data source is sorted.
Personally I tend to steer clear of { SKIPIF } on the grounds that
a. it was "deprecated" by Microsoft several versions ago - or at the
very least, its use was discouraged
b. it doesn't really do what a user might imagine it does given the
name - i.e. it doesn't simply skip records in the data source; it skips
records in the data sorce /and/ causes Word to finish processing the
current copy of the mail merge main doc. and start a new one. Which may
be exactly what you want in some cases but will almost certainly screw
you up in, e.g., label merges.
However, that's just my view, and there are certainly cases where it's
probably the simplest solution. The introduction of the OOXML standards
certainly makes you wonder what Microsoft will do with its "field
language" in future versions. If it wants to conform to the standard, it
would probably have to change the way fields work, because AFAICS there
are certain areas in which the standard conflicts with current reality
(for example I do not think it describes the field parameter syntax that
allows use of { QUOTE 13 } to insert a CR, and I think it specifies that
{ DATABASE } always inserts a table, whereas in fact it does not if the
table would only consist of one cell. However, I'd have to check the
standard much more thoroughly to be sure. However, since not conforming
to the standard would screw a lot of applications up, and modifying the
code would probably be expensive, it seems much more likely that current
field behaviour will be ossified and complaints that Word is
non-conformant will be dismissed somehow or other.
Peter Jamieson
http://tips.pjmsn.me.uk
macropod wrote:
Hi Peter,
Presumably one could also embed a SKIPIF field in the mailmerge main
document, coded with logic that is functionally equivalent to the filter
in Excel.