Merge Field Problems

[jamusselman]

I am in the process of upgrading to FMPro 9. Many of my layouts make heavy use of Merge Fields. These used to work just fine but with FMPro 9 any merge field that is a calculation displays the field name and not the field contents. The content displays correctly if I don't display it as a merge fields.

What's also weird is that so long as I don't touch an existing layout all is fine. But as soon as I do anything - change a font color, size, etc. - it changes to displaying the field name vs. the content. Any new layout is messed up no matter what I do.

Any suggestions would be greatly appreciated.

[Vaughan]

It should "just work."

Have the field names been changed? Are the layoits pointed to the correct table/TO?

[LaRetta]

Are the layouts pointed to the correct table/TO?

As Vaughan says, it is important that, if you place a merge field on a different table occurrence than it originated, you place the table occurrence name in the front of it.

Was this an upgrade from vs. less than 7? Anyway, if the field specified by the merge doesn't come from the same table occurrence, you need to list it like this: <

[jamusselman]

Yes, I have the table name in front of the field. It works as expected for just a plain field but inserting it as a merge field cause the whole field name to be displayed vs. the value of the field.

For example, from my table "Family", I want to print out "FamilyXtra::DirectoryEntry". If just a plain field is inserted in the layout I get something like:

John Smith

123 Main Street, Anytown, USA 20000

If I insert it as a MergeField, I get

<

<

[Vaughan]

Are you typing these merge fields in by hand? Use the Insert menu to make sure they are correct.

It sounds as though the table occurrance names have changed.

Also make sure the TO of the layout is correct. It could be that the TOs aren't related.

[jamusselman]

I'm using the menu to insert the merge field.

When you say table occurrance I'm not sure what you mean. I have a several tables that are all related with a familyID field. I've checked it a couple of times and it all looks ok to me but I'm not an expert at this stuff. It all worked ok until I migrated to Version 9. Also, it's all ok UNTIL I try to adjust something in the layout. Just changing the font size causes the problem.

How do I check the table occurrance?

Thanks again.

[LaRetta]

<>

The time within the string indicates that FM does not recognize that table occurrence.

Why is there a [c] within the string? It appears to indicate that that table occurrence isn't related because that's how it will display if not. It might not be recognized as related because of that [color:green][c] which brackets are invalid characters in field/table names.

[jamusselman]

1) Why is there a [c] within the string?

The field DirectoryEntry is a calculated field. I did some more debugging, inserting diferent types of merge fields from every related table. I displayed the field FamilyID from each of the related tables. It was the same value in each case. Values displayed correctly if they were just a plain text fields. If they were any other kind of field (calculation, global, etc) they displayed the field name with the time stamp, not the field value.

2) Where was this migrated from? What other version?

I had been using FMPro 6, although all the previous files had fp5 as an extention.

[Vaughan]

Remember when you created the field how FileMaker gave you a warning that the feld cannot be used in a calculation because it contains in illegal character?

Remove the "[" and "]" characters from the field name and it'll work.

While you're editing field names, go through all the other fields and clean them up too.

[LaRetta]

If they were any other kind of field (calculation, global, etc) they displayed the field name with the time stamp, not the field value.

Do you preface your fields (calculations, globals etc) with the bracket and type?

Again. This is invalid. Relationships based upon a field as the key which begins with [c] will NOT produce a valid relationship. Field names beginning with it will NOT display properly but will display as: <<[c]fieldname >>

If you have a merge field which is an unrelated table, it will look like this in Layout mode:

<> but like this in Browse:

If you are copying your layouts and pasting them, then those merge fields will not inherit the 'file' name from prior version. Did you properly migrate up in versions or are you just copying the layouts? The time displaying like that indicates that FM does not recognize it.

UPDATE: Hi, Vaughan! :bye:

Edited October 25, 2007 by Guest

[LaRetta]

Here is how to replicate the time displaying in the middle of the merge field:

Place a merge field from Parent on a child layout. But have the parent field be invalid, ie, text[c] or [c]text etc. When in layout mode, they display correctly but when you go to browse, they display the time.

[comment]

Not that I would recommend it, but you CAN merge fields with invalid names this way:

 <<${BadFieldName}>>

It seems that Filemaker dislikes this so much it makes you rewrap the invalid field name every time you edit the text object containing the merge code.

Edited October 25, 2007 by Guest

[LaRetta]

You'd mentioned this before - about using invalid field names within calculations. But I had forgotten about it! Agreed ... I wouldn't want to always remember to manually add that protection to my merge or calculation fields but it is a good thing to remember.

[LaRetta]

Wow! It surely does! If FM dislikes it so much, I think I'll steer clear!

[jamusselman]

I feel like I'm a little over my head here....

I did not copy/paste layouts. I started with FMPro 6 databases. After installing my new FMPro 9 I opened my *fp5 files. FM did some conversion, making copies of my fp5 files and creating new fp7 files. I did not do any other migration steps. Should I have?

The fields I'm using to form relationships are just plain indexed text fields (FamilyID), not calculations.

When you say I should remove "[" and "]" from the field, where should I do this? In the layout? In the database field definition? So far I have been unsuccessful in getting this fix to work so I'm probably doing something wrong.

I find it confusing that they mergefields seem to work correctly UNTIL I make a change to them in the layout. Just changing the font color of a mergefield cause that, and only that, mergefield to change to the mergefield name with the timestamp. And why does it work if I insert a field in the layout but not if I insert that same field as a mergefield? This happens whether it is a field in a related table or a field in the current table.

Thanks.

...Joyce

Edited October 25, 2007 by Guest

[LaRetta]

After installing my new FMPro 9 I opened my *fp5 files. FM did some conversion, making copies of my fp5 files and creating new fp7 files. I did not do any other migration steps. Should I have?

I don't know. If you had several files and you began by dragging one file to FM shortcut (and if you saved the newly created files as they were converted in the same folder), then you may have some breaks throughout your solution. All files should be converted simultaneously in a new folder. Here are some references to read:

Migration_foundations

FM8_Converting

The fields I'm using to form relationships are just plain indexed text fields (FamilyID), not calculations.

Re-read my post a few above #270544, where I mention "...have the parent field be invalid. I didn't mention invalid relationships here at all. To produce the broken merge display, the FIELD can be broken even if the relationship is fine. I realize I gave you several examples and I regret confusing you with them. But I couldn't see your solution so had no idea [color:green]what was causing your breaks; I only knew [color:green]several reasons that they could break that way.

When you say I should remove "[" and "]" from the field, where should I do this?

Right, in the database field definition. But even if you correct it now, I do not believe your merge fields will 'fix' themselves. A merge field which is broken can't identify the table occurrence/field it belongs to (because it is broken). So it can't fix itself to align with the proper table/field when corrected in your field definitions.

I find it confusing that they mergefields seem to work correctly UNTIL I make a change to them ...

Actually that makes sense in a way. The conversion doesn't recognize that your merge fields are broken because merge fields are layout objects. If you reviewed your Convertion Log, you would have probably seen errors saying your [color:green]field names were invalid. The breaks in your merge fields do not show until a CHANGE is made to your layout because FileMaker doesn't re-evaluate the elements until you go back to Browse mode; at which time FileMaker recalculates/draws the layout and THAT is when FM becomes aware of the break.

What would I do at this point? Only you can decide, Joyce. We don't know how much time you've put into this new vs. 9 solution. If all you are losing are your merge fields, it might be worth just re-doing them. But I'd look closely at all calculations, scripts, layouts etc to be sure nothing else is broken. I wish you well on your project and let us know as you progress on it.

LaRetta

[The Shadow]

I suspect once you fix the field names in define database to not have "[", "]" or other weird chars all your merge fields will be fine.

There is clearly a bug in FileMaker that it only poorly supports "invalid" field names in merge fields.

The reason this is happening is that FM 6 did not reserve "[" and "]", as they had no special meaning there, but FM7 and above use these characters for several things.

[Fenton]

Trivia question: FileMaker objects to the word "Other" as a field name. What function uses "other" as a parameter?

[Raybaudi]

Hi Fenton

look at TextFont ;)