Hi Cindy,

Thank you for another prompt reply.

Oh yes, don't worry, the formatting issue is not to do with how the
merges themselves appear, but the layout of the report itself. It is
very complicated, sporting different font styles, borders, backgrounds
etc all over the place; it also needs to be easily changed by other
members of staff who can use Microsoft Word, but not microsoft Access,
nevermind the report editor.

So basically, I'm still just stuck on the things mentioned in my
previous message to you (please see below), and am just not sure what
each part of the code does in that example in order to change it to fit
my needs.

If you could explain the following sample of code, that would be great!

{MERGEFIELD Employee} {MERGEFIELD Project}{set duplicate {if
{MERGEFIELD Check}="1" "off" "on"}}{nextif {mergefield check}=""}{if
{duplicate}="on" "P t

I realise P and T mean Paragraph and Tab, so understand those; it's the
point of the "1", "off" and "on" that I am not sure of, and just what
the code is doing in relation to those. I'm certain that this code is
doing just what I require, but just do not know how to alter it for my
scenario.

As always, your help is very much appreciated!

Contro.

Cindy M -WordMVP- wrote:
Hi Contro,

OK, I read your message to Doug and you mention "very exact formatting".
Before we get too deeply into this approach, could you describe what kind
of formatting is meant?

IF fields do a fairly good job with Font formatting. Paragraph formatting
can get a bit "iffy" under some circumstances. If things are really
complex, a macro solution might be the better approach.

As to the article and the example:

I see this is an older article. A better example is here
http://support.microsoft.com/?kbid=211303 (thanks for asking and thus
bringing this to my attention). This article should make more sense (and
I apologize for the confusion due to the old article!)

Thanks for you reply. My database is fully normalised (so far as is
required anyway! I'm no expert on it, but it's all up so the
relationships are right and the primary and foreign keys are in place).

The code of the knowledge base example is:

Employee Project
{MERGEFIELD Employee} {MERGEFIELD Project}{set duplicate {if
{MERGEFIELD Check}="1" "off" "on"}}{nextif {mergefield check}=""}{if
{duplicate}="on" "P
t{MERGEFIELD Project}"}{set duplicate {if {MERGEFIELD Check}="1"
"off" "on"}}{nextif {mergefield check}=""}{if {duplicate}="on" "P
t{MERGEFIELD Project}"}{set duplicate {if {MERGEFIELD Check}="1"
"off" "on"}}{nextif {mergefield check}=""}{if {duplicate}="on" "P
t{MERGEFIELD Project}"}{set duplicate {if {MERGEFIELD Check}="1"
"off" "on"}}{nextif {mergefield check}=""}{if {duplicate}="on" "P
t{MERGEFIELD Project}"}

From what you mention, I see that the code basically looks for items
which have a primary key - foreign key match (subjects that belong to
the same student). I'm just not sure how to use this code to my
situation though. Above, the code seems to be looking for a number in
a "check" table which is 1; I've no idea why. Also, I do not
understand all the "off" "on" business at all or how they relate to the
"1" that is specified and whether they need to relate to a 1, or if
this is just something that is only part of this example and isn't
necessary (not something I'd need to use in my own database).


Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail :-)