Lack of logs from DB::connect(), and can Pear::DB talk to a socket?

Pardon me for hijacking the "problem using Pear's DB layer" thread, but > i did this and it stops after the statment > $db = DB::connect($dsn); > > or to put it differently, no print("foo"); is printed after that line. > but i checked the include path and it seems to include things fine! This sounds like a problem I was just having with Pear and PostGreSQL under FreeBSD. All html output would end with the last debug print before the DB::connect(); and there was no complaint of any sort in the logs. As I was preparing to post the code here, I noticed that I had forgotten to change the dbtype field from mysql to pgsql. After I fixed that, my apache logs told me that PostGreSQL was refusing connections, and then I was able to proceed from there. It turned out that I also had to use the -i flag for postgres's control programs, to enable talking to the loopback. I hadn't needed the -i flag for using php's pg_xxxx() functions, php just grabbed a socket, I think. I'm guessing that's because the connection string is using the DSN format? So here's my question: Is there some way to define a connection string that would allow Pear to use a socket? > i don't know if this has anything to do with it but, when i put html code before the > script > it prints it twice. I didn't have this double HTML, however. This lack of log seems a little buggy to me, or is explicitly querying DB::isError() and $db->getMessage() considered preferred over the usual logging? (I'm also getting a method undefined log on the call to getMessage(), but I suspect that's because my Pear or php are down-level on the FreeBSD box at this point.) Hmm. Come to think of it, I also have MySQL installed, incompletely set up, but running on the FreeBSD box. I suppose it might be too much to expect Pear to recover from that. -- Joel Rees <joel@alpsgiken.gr.jp>