You don't say what you're attempting to do when you get this error, but often, this is the result of trying to fetch a too-large record set. You can try setting the range of the records to a fixed value and see if that helps.
I would check how big your found set is and/or if you're pulling records with a portal how many rows that's pulling along as well. This is likely the culprit.
Only fetching name, addr, etc of one record, and none of the records have fields that somebody filled with a ton of junk. So this kind of confirms the error. Something goes wrong and the return which should be a little data is sending a flood of data.
confirm that you are using the right API library for your server. We've
seen odd problems when we have mis-matched the API and the server version.
It looks like you're using WordPress; that's going to have some overhead in addition to the FMP API and the data you're requesting. Bump your memory limit to something obscene like 256M:
ini_set("memory_limit" , "256M");
Then dump the data you get returned to verify you're really only returning one record like you think.
Hey Tom, I agree with Mark here. Are you potentially running a script in FileMaker? Do you know what the found set is when you're finished?
Every other time I've seen this error, it's because someone is running a script and is pushing back the entire found set back to the PHP API to parse into an object. The reason I mention scripts is because unlike issuing a tradition find query, or new or edit record, the found set acts like FileMaker Pro where it defaults to all records.
You could continue to change the settings on your php.ini file to up your cache, but if you're pulling enough data to run into a memory error, it would be better to fix your solution to not send that much data.
It is likely that the line calling the curl_exec is where you get an error, but keep in mind that the php api is just a wrapper for the web publishing xml api.
Check that the results returned are not too large. Either the found count of records is too large, or there is too much data on the layout in the form of portals and such. How many records are you expecting to get back, and also how many fields are on the layout that you are hitting?
You could always bump up the memory limit for PHP, but if you're on shared hosting, you may not have access to be able to do that.
I don't THINK I'm flooding data back to php on end of the script but I need to understand something given messages here. The last functions of the script go to a layout, make a new record, copies a var into a field, end. No exit with parameter. Nothing should be being passed back to php but that the request to run the script is acknowledged and done. Note that my sequence, - go to layout, make new record - does mean it might be left with all records as the found set, but I'm not trying to pass anything from that back to php. Is the mere fact that I left off on a layout with all records showing automatically going to pump all that data back to php? If it is then as a last step I could do a find for just the record I just made. But I would be amazed if it's going to send all that data back without being asked to.
Do you mean a FileMaker script, or a PHP script? From the way your statement is worded, I think you mean FileMaker, so I'll go with that. (Correct me if I'm wrong.)
In my personal experience, for something as simple as what you're describing, you're better off just using PHP to perform the task. The application tends to perform better. I've had problems similar to what you describe when trying to execute a script in FileMaker from PHP, so I try to avoid it unless I need to use FileMaker scripting for something I can't do in PHP.
I suggest you use PHP to create the new record and then insert the value you need.
FileMaker returns the found set of records to PHP at the end of your script. That's the way it's always worked and can be very useful if you want to script your find with FileMaker rather than PHP.
So yes, based on what you wrote, you are returning all records for that table which is why you're blowing your memory limit.
Either change it like Mike mentioned by inserting via PHP or set the found set to be only the newly added record before your script returns.
Good info, Mark. Thanks!
You're right, I didn't specify, but yes I was describing the FM script. There's more going on so I think it better to keep it in FM.
"I've had problems similar..." This is really discouraging. There's much that would be nice to do in FM scripts and it seems such light work for the php for it to just call a script. Anything in particular to avoid or watch out for, or just general inconsistency? Come to think of it early on the php programmer couldn't get a call to an FM script to work right that just generates a random pwd and returns that short string. He gave up and generated it in php.
I think Mark gave you the answer. Prior to exit, restrict the found set.
The one thing to always keep in mind is that running a script starts a new session, and the script will run similar to if it was running in Pro. The biggest thing to think about though is that the layout and found set you end up on determines what data is sent back to the PHP API. If you run a script in Pro on startup that goes to a layout and creates a record, what's your found set if that file is on Server? It's all records + the record you added, so that is what is being sent back to the API.
There are two options to fixing your issue: the first one is to either rewrite you API call to just create a record instead of calling a script. This is handy if that's all you are doing, but if you need to do more, then this might not work.
The other option is to control your found set. For example, after going to that final layout, add the script steps:
Show All Records
Show Omitted Only
This will give you a found set of no records. Then when you create your new record, that's the only thing that will be passed back to the API.