ID: 29107 Updated by: [EMAIL PROTECTED] Reported By: bart at mediawave dot nl -Status: Feedback +Status: No Feedback Bug Type: Apache2 related Operating System: Win2k PHP Version: 4.3.7 New Comment:
No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: ------------------------------------------------------------------------ [2004-11-22 14:07:19] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. ------------------------------------------------------------------------ [2004-08-13 05:20:02] loye dot young at iycc dot net If you have the PEAR Date package installed, this may be the problem: There is a command in a Pear function that tries to write information to the server. Some Windows installations and Unix servers with strict Safe Mode options enabled do not allow this. You can fix this yourself however. Open the file lib/pear/Date/TimeZone.php in a text editor. Go to line 247. You should be in a function named 'inDaylightTime()'. Add this line: return date("I"); at the very top of the function. It should now look like this: function inDaylightTime($date) { return date("I"); $env_tz = ""; if(getenv("TZ")) $env_tz = getenv("TZ"); putenv("TZ=".$this->id); $ltime = localtime($date->getTime(), true); putenv("TZ=".$env_tz); return $ltime['tm_isdst']; } This should stop the error. Perhaps in the future, the Pear team will supply a work around. See if that fixes it and let everyone know. ------------------------------------------------------------------------ [2004-07-23 15:55:42] bart at mediawave dot nl I don't think that's my problem. I'm having the problem at my testing server where, most of the time, I'm the only client. So ,if persistent connections work like they should I guess, in my case, there's only one conection there. ------------------------------------------------------------------------ [2004-07-23 15:34:59] super_freax at hotmail dot com It says in the PHP-manual for child operations that : This means that for every child that opened a persistent connection will have its own open persistent connection to the server. For example, if you had 20 different child processes that ran a script that made a persistent connection to your SQL server, you'd have 20 different connections to the SQL server, one from each child. Note, however, that this can have some drawbacks if you are using a database with connection limits that are exceeded by persistent child connections. If your database has a limit of 16 simultaneous connections, and in the course of a busy server session, 17 child threads attempt to connect, one will not be able to. If there are bugs in your scripts which do not allow the connections to shut down (such as infinite loops), the database with only 16 connections may be rapidly swamped ====== So it might be the database that has no more connections left ? My Config is : WinXPProSP1 (NTFS Formatted) Apache version 2.0.49 MySQL 4.0.18 with MyODBC 3.51 and winMYSQLadmin 1.4 PHP 4.3.6 with Pear 1.3.1 ,Smarty 2.5.0 ,Zend Opt. 2.5.0 , Dbg 2.16.3, TCL 8.4.5 with TK 8.4 and Vtcl 1.6.0 ------------------------------------------------------------------------ [2004-07-13 12:57:28] bart at mediawave dot nl That didn't work. I still get the error. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/29107 -- Edit this bug report at http://bugs.php.net/?id=29107&edit=1
