Conditional use of merge fields suddenly failing

[rgutter]

I've been using this to prepend an area code - if one is supplied - to
a phone number:

Phone: { IF { MERGEFIELD AreaCode1 } <> "" "{ MERGEFIELD AreaCode1 }-"
"" }{ MERGEFIELD Phone1 }

Because I allow the user to select the type of contact information on
the input form, I wrap the above within another conditional:

Phone: { IF { MERGEFIELD Type1 } = "Phone" "{ IF { MERGEFIELD AreaCode1
} <> "" "{ MERGEFIELD AreaCode1 }-" "" }{ MERGEFIELD Phone1 }" "" }

Not too elegant, but it works. Or at least it did, until two weeks ago.
Suddenly, on a single client machine (XP Pro, Office 2002), area codes
refuse to print. I've copied the data source to several other computers
and enviroments, and all is ok. I'm baffled. Can anyone think of any
sort of MS update the client might have loaded that could affect this?

 

[Cindy M -WordMVP-]

I've been using this to prepend an area code - if one is supplied - to

a phone number:

Phone: { IF { MERGEFIELD AreaCode1 } <> "" "{ MERGEFIELD AreaCode1 }-"
"" }{ MERGEFIELD Phone1 }

Because I allow the user to select the type of contact information on
the input form, I wrap the above within another conditional:

Phone: { IF { MERGEFIELD Type1 } = "Phone" "{ IF { MERGEFIELD AreaCode1
} <> "" "{ MERGEFIELD AreaCode1 }-" "" }{ MERGEFIELD Phone1 }" "" }

Not too elegant, but it works. Or at least it did, until two weeks ago.
Suddenly, on a single client machine (XP Pro, Office 2002), area codes
refuse to print. I've copied the data source to several other computers
and enviroments, and all is ok. I'm baffled. Can anyone think of any
sort of MS update the client might have loaded that could affect this?

Mmmm. Need to ask some questions...

1. What's the data source?

2. If you've (or the user) changed the connection method from the
default, what are you using? Or are you using code to connect the data
source?

3. If you insert just the AreaCode1 field, into a new document, as a
test, you see absolutely nothing when you page through the records?

My best guess, based on the information you give, would be that this is
an Excel source and the data in the AreaCode column is mixed
numeric/text. However, the fact that it works on other machines makes me
hesitate, unless it's an issue with the connection method.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
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

 

[rgutter]

Hi Cindy,

Sorry, I should have started by saying I'm rolling my own mail merge
here within a Word macro.

The data source is an XML file created via VB6/ADO from an Access 2000
database. In the test case, it contains just a single record. The Word
macro opens this file and replaces each MERGEFIELD in the new document
with the value of the named field.

And yes, if I strip it all down to just the AreaCode1 field, the new
document is empty.

All that I can think of is that some new DLL is causing a screw-up in
the evaluation of Word "IF condition true-output false-output" fields
when they're nested, but that seems so unlikely. Or at least unlikely
to have gone unnoticed.

BTW, here are the contents of a sample XML file:

<xml xmlns:s='uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882'
xmlns:dt='uuid:C2F41010-65B3-11d1-A29F-00AA00C14882'
xmlns:rs='urn:schemas-microsoft-com:rowset'
xmlns:z='#RowsetSchema'>
<s:Schema id='RowsetSchema'>
<s:ElementType name='row' content='eltOnly' rs:updatable='true'>
<s:AttributeType name='AreaCode1' rs:number='19' rs:nullable='true'
rs:maydefer='true' rs:write='true' rs:basetable='Address'
rs:basecolumn='AreaCode1'>
<s:datatype dt:type='string' dt:maxLength='4'/>
</s:AttributeType>
<s:AttributeType name='Phone1' rs:number='20' rs:nullable='true'
rs:maydefer='true' rs:write='true' rs:basetable='Address'
rs:basecolumn='Phone1'>
<s:datatype dt:type='string' dt:maxLength='36'/>
</s:AttributeType>
<s:AttributeType name='Type1' rs:number='18' rs:nullable='true'
rs:maydefer='true' rs:write='true' rs:basetable='Address'
rs:basecolumn='Type1'>
<s:datatype dt:type='string' dt:maxLength='10'/>
</s:AttributeType>
<s:extends type='rs:rowbase'/>
</s:ElementType>
</s:Schema>
<rs:data>
<z:row AreaCode1='701' Phone1='333-2398' Type1='Phone'/>
</rs:data>
</xml>

 

[Cindy M -WordMVP-]

And yes, if I strip it all down to just the AreaCode1 field, the new

document is empty.

Mmm. Then in this case, I'd say the problem is in the "transmission":
however your code is passing the data. Do you have any checks in there
whether the Mergefield is actually being found? Is it possible it's
not being found, so the information isn't being inserted?

Have you checked the document this user has on another machine?

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
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

 

[rgutter]

Thanks Cindy. I realize now that I don't surround my replacement values
with quote marks, even when they're IF operands - perhaps that's
causing problems. E.g., the example above becomes
{ IF Phone = "Phone" "{ IF 701 <> "" "701-" "" }333-2398" "" }

which then becomes
{ IF Phone = "Phone" "701-333-2398" "" }

which - if Word recognizes the equality - should resolve to
701-333-2398 (which is what happens on all computers but the one)
or otherwise to nothing. Why I'm seeing 333-2398 on that one machine is
still a mystery. I'll post here when I figure it out.