FileMaker Addict Has Moved!

FileMaker Addict can now be found here: http://www.filemakeraddict.com




Thursday, February 07, 2008

Overcoming the Dreaded 102 "Field is missing" Error

I recently encountered an error that I know other developers have run into. It's "Error 102" which indicates that a referenced field is missing. The error started to be thrown by one of our PHP applications. The code that was throwing the error is used to find a record. The bizarre thing about the error being thrown is that nothing -- and I mean nothing -- had changed in the FileMaker database.

Here's what I did to resolve the issue...

1. I first confirmed that the layout being used to do the find (the layout being referenced by the newFindCommand method) was the correct layout, and that the name was spelled correctly in the PHP code. It was.

2. Next, I confirmed that the field being searched on was on that layout, and that it's name was spelled correctly in the PHP code. It was.

3. I then checked to see if the FileMaker account that PHP is using to access the database has the permissions that it needs to access the data. It did.

4. I then tried restarting Web services, and that didn't help.

5. At the desperation stage now, I shut down FileMaker Server, and rebooted the server. This had no effect, as the dreaded 102 error was still being thrown.

6. I decided to "give PHP something to cry about" and actually removed the field that it claimed it couldn't see. I saved the layout changes. I then went back into layout mode, added the field back, saved the changes, and...

Voila! That worked!

I have no idea why this worked, but it did.

So if you run into this same issue, where PHP suddenly cannot "see" a field that you know is on a layout and that it should be able to see, remove the field from the layout and add it back.

- Tim

22 comments:

Denis said...

Hmmmm... interesting. I would keep an eye out for database corruption. Make sure you're doing backups as often as you need to!

Pete Bowen said...

I'm about to try this workaround but I was wondering if it is possible to access a field from an external table that is on a layout?

I have the raw data in a layout and another layout for the UI (separation model) and keep getting this error when trying to access fields from the data file in the UI layout.

Thanks

Pete

Tim Dietrich said...

Pete --

Are the UI and data files being hosted on the same server?

-- Tim

Pete Bowen said...

Yes, they are both on the same server - my mac mini set up for testing.

I wonder if one needs to include table information with the field name something like "table1::field1".

Tim Dietrich said...

Pete -

Yes, that's close. Instead of specifying the table name of the related record, you need to use the relationship name for example...

echo $Orders->getField('Orders to Lineitems::Item_Number')

That should do it.

-- Tim

Pete Bowen said...

Unless I'm being dumb (and that has been known to happen) using the full relationship name doesn't work either.

It's not a privileges thing because both databases are set for full access on my testing server.

Perhaps this is something that needs to be addressed in a future update of the program.

Tim Dietrich said...

Pete --

That is odd, because it is something that I have been doing for quite awhile...

I would check the following:

* Make sure the related field is on the layout that you are using to access the database from PHP.

* Make sure that you are using the correct relationship name and field name.

* Confirm that the account that you are using to access FM from PHP has access to the related table.

Let me know if I can be of any further help.

Good luck!

-- Tim

Pete Bowen said...

Thanks Tim,

I appreciate the pointers.

For now I am living with a work-around entering information directly into my raw database from the web.

This is my first attempt at cwp so it has been rather frustrating so far.

I will play with this once I have finished the stuff that I am working on.

Cheers

Pete

Derek said...

I have converted 99 tables from 6 to 9. I am finding these 102 errors using the script debugger in 9 advanced. The thing is, the fields are there, in the layout. The scripts that reference the fields were all converted as well.

The only thing that corrects this is deleting the field off the FMP layout, saving it, then going back in and re-adding it. That seems to satisfy this 102 beast.

I do not feel your troubles have anything to do with PHP, as I am having the errors when using the raw FMP interface.

I do seem to have the errors primarily on global fields, though.

Derek

theamoeba said...

thanks, figured that i had not added the field to the layout.

Tim Dietrich said...

I've run into the 102 error again, and have some new insights about it...

This morning, I noticed that a field that was clearly on the layout being referenced wasn't accessible by PHP. The permissions were okay, so that wasn't the problem.

Then I realized that the layout was setup in such a way that it was only available in Table view, and that this was the default view. There are a lot of fields on this layout, and in Browse mode, the field that PHP couldn't access wasn't visible.

I modified the layout so that List view is also available, and made this the default. And - surprise! - the field is now available to PHP.

I then did some research. While there doesn't seem to be a hard limit to the number of fields that are displayed in Table view, it appears that there is a physical limit (number of inches) to the width that can be displayed.

I then changed the layout back to Table view, resized a number of the fields on it, until there was enough room for the "missing" field to display... And that solved the problem. PHP can now see the field properly.

So it seems that PHP's ability to access fields is dependent upon the layout in more ways than I had ever imagined... And I don't think it should be.

I hope this helps someone else who is also struggling with the 102 error.

David said...

THANK YOU Tim! Saved me a bunch of aggravation. I echoed out all the fields on the layout but now that I think of it, it gave me the fields in the TABLE. A little deceptive. When I could physically SEE the fields on the layout, the problem went away. Your observations were extremely helpful. In future, I think I will make an all-fields layout used exclusively for working with PHP code.

David

Tim Dietrich said...

David --

Glad this helped!

You mentioned that you might build "an all-fields layout used exclusively for working with PHP code." I highly recommend against this, because the overhead of sending back all that extra data is significant. If you get a chance, read the article that I wrote for FMWebSchool about optimizing FM/PHP apps: http://www.fmwebschool.com/newsletter/webopt.pdf There's good info in it about the impact of extra fields on layouts that the are used with the API.

-- Tim

Adam said...

I'm having this problem right now, but I can't seem to get rid of it. I can't access any field from my data file via a UI layout. I can access the data file directly, but I don't want to do that. Is there any other information on this?

Tim Dietrich said...

Adam --

"I can't access any field from my data file via a UI layout. I can access the data file directly, but I don't want to do that."

Is the UI layout in the same physical file as the data itself?

-- Tim

Gregory said...

How did you determine which "field is missing". What I am currently seeing in this message is as follows:

"Error 102: Field is missing"

Without the quotes...

Thanks,

greg

Tim Dietrich said...

Greg --

I was able to determine which field the error was being thrown about by commenting out the PHP code that referenced the data, and gradually uncommenting it until the error re-appeared.

Hope this helps!

-- Tim

Gregory said...

Thank you for your response.

That's kind of what I thought you did, so I felt lucky and tried deleting the field that had caused the same problem some time ago on a different site as you describe n this blog.

HURAY It worked!!!!

Don't know why...

greg

coeurdeberger said...

Cannot Add Field to Layout
FM novice here, about 6 months after 25 years as an amateur dBase programmer.

Strange new problem: I can add a field to the database (Manage Database), but when I try to add the field to the layout ("Specify Field"), it is not in the list. I've done this hundreds of times with no problem, but suddenly, the Specify Field list does not list all the fields in the database. Any ideas?

coeurdeberger said...

Problem solved. I deleted all the other database copies and the problem is solved. Don't ask me why!

Anonymous said...

I've found this can happen for a couple different reasons:

1. Typo in the field name in the web form
2. Field doesn't exist on the layout reference
3. Response page isn't calling the correct db or layout

Anonymous said...

I had a similar frustrating problem. It went away when I changed the entry in the External Data Source File Path List from fmnet:/… to file:/….

Hope my time spent banging my head against the wall can save someone else the frustration.