Richard Munroe - 2006-06-03 13:36:58 - In reply to message 1 from NoiseEee
All I can say is that it works for me on every database that I have access to. I'm primarily using PHP 4.4.0 on a Debian system. I'd suggest spending some time trying to debug it since there are some fairly substantial incompatibilities between earlier versions of PHP and 4.4.0 (I've found a number of classes that don't work at ALL with earlier versions) and I'm not planning to chase those unless I run into problems personally (I will gladly accept fixes for those environmental problems, however).
There is a loop early on that enumerates the tables in the database, see what's being returned there and let me know. Basically I can't debug it in your environment and have to assume that, since it works here, that there is some sort of environmental problem at your end. It's possible that your PHP environment needs to be reconfigured as well. I typically run allowing PHP substantial resources (much larger than defaults) which could potentially affect the running of the backup script.
My guess is that your version of PHP doesn't honor either persistant connections to mysql OR that it doesn't do the right thing when copying references (both of which I've seen depending on the version and configuration of PHP). If it's the latter, you'll need to figure out what to do to get a "clean" copy of the database object so that you can read the tables without loosing state when attempting to access the meta information about the tables. I forget what I did when I ran into the former, probably tweaked something in the PHP .ini file but I forget (it's been years since I've seen that particular problem).
FWIW, if you're using a Red Hat system <= 9.0 then they are using an old and [somewhat] buggy version of PHP (4.2) as their standard release version. I would suggest upgrading PHP ASAP and trying again. One of my clients rents time on a RH 9.0 box and it's been a real pain since the ISP won't upgrade it without RPMs.