Hi Tom,

If you set the name and value to "primaryEmail" you will get true stored in the database. Here's a sample using the DataRecord class from the tools.jar:
dataRecord.setName("contactEmailAddress");
dataRecord.setAction(org.aspcfs.apps.transfer.DataRecord.INSERT);
dataRecord.addField("contactId", 1);
dataRecord.addField("type", 2);
dataRecord.addField("email", "test@example.com");
dataRecord.addField("enteredBy", 1);
dataRecord.addField("modifiedBy",1);
dataRecord.addField("primaryEmail","primaryEmail");
connection.save(dataRecord);

As you thought, this is because of the way the XML HTTP API works. Incoming requests to the ProcessPacket class are read and the elements are mapped to their base class, in this case, ContactEmailAddress. Each child element is then populated in the object through the setter methods. The unexpected behavior is caused from an overloaded setPrimaryEmail method that accepts a String. This method breaks convention and sets the field to true only if the String is "primaryEmail."

- Lorraine

Thank you very much, Lorraine! This was very helpful information. I'm certain I wouldn't have figured that one out on my own =)

Along the same lines, are there other areas where there are other potentially confusing XML API strings like that one? For example, it seems that the contactAddress class might have the same issue...?

Thanks again!

Oh... nevermind. The contactAddress class works just fine with "true" and "false"! But are there other places you know of?

In this case, we'll update the class to allow the more conventional "true" by changing the setter:

public void setPrimaryEmail(String tmp)
this.primaryEmail = ("primaryEmail".equals(tmp) || DatabaseUtils.parseBoolean(tmp));
}

We'll maintain backwards compatibility with the word "primaryEmail." Address and phone only accept true/false.