Jump to content

Merge Field Problems


This topic is 6085 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies

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.

Link to comment
Share on other sites

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: <

Link to comment
Share on other sites

  • Newbies

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

<

<

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • Newbies

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.

Link to comment
Share on other sites

<>

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.

Link to comment
Share on other sites

  • Newbies

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Guest
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Guest
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • Newbies

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 by Guest
Link to comment
Share on other sites

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. :wink2:

LaRetta

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This topic is 6085 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.