Issue with Upgrade from 5.2.17 to 5.3.20?

[Remix919]

I just recently upgraded to PHP 5.3.20 and now suddenly I'm having issues with my code, with just simple things like mysql_fetch_assoc and mysql_query?

I'm getting issues like:

Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given

and when I do a mysql_query INSERT it looks like it works fine, but no entry appears in the database.

All this was working perfectly prior to the upgrade to 5.3.20 from 5.2.17, any idea what's going on?

[Fou-Lu]

The upgrade itself wouldn't have changed the functionality of the mysql library. Its likely your configurations that do not work.
The issue is simply that your query has failed and you don't have proper error handling in place. Given that it worked on a previous build and not on the 5.3 build would tell me that its your configurations that have changed in your ini environment. Perhaps you are relying on magic_quotes_gpc or register_globals (both gone as of 5.4; deprecated as of 5.3).

[Remix919]

The error I get is "MySQL server has gone away", I looked up this issue but seems to be a multitude a reasons, but basically means the query timed out? Is there a setting in the php ini file that would affect this?

[tangoforce]

It could be many things. I've had the sql server gone away message a few times myself. I can't remember what caused it but I know I had to tinker with a few settings and the code too.

Watch out for date and mktime functions too. I can't remember what but I ran into trouble with both of those when tranferring my code from my 5.3.0 wamp to a linux 5.2.7 setup which gave me a lot of head scratching moments to deal with.

[Remix919]

Figured it out, it was the mysql connect_timeout setting, after all the upgrades and whatnot it apparently got set to 8 seconds, I increased it to 60 and everything works fine now

[tangoforce]

Thats still a long time for a mysql connection though.. that must be one busy server!

Actually thinking about it, have you optimised your sql calls so limit them to as few as possible? - if you're running several hundred per script then you can grind a SQL server right down. I'm not saying thats what you're doing but just putting forward an idea just in case.