php-Dev archive @ ASPN

#37875 [Opn->Ver]: while(list() = each() ) on simplexml_element loops forever

ID: 	      37875
 Updated by:	   tony2001@...
 Reported By:	   jona at oismail dot com
-Status:	   Open
+Status:	   Verified
 Bug Type:	   SimpleXML related
 Operating System: Windows 2000
 PHP Version:	   5.1.4


Previous Comments:
------------------------------------------------------------------------

[2006-06-21 15:24:29] jona at oismail dot com

Description:
------------
When doing a while (list($key, $val) = each($obj_XML) ) on a Simple XML
object PHP loops forever.

Is this possibly related bug: #24945 foreach on simplexml_element loops
forever?
Please note, for each works but only output the tag not the attribute.

Found on Windows 2000 running IIS with PHP5.1.4 as an ISAPI module.

Reproduce code:
---------------


Jona
';

$obj_XML = simplexml_load_string($sXML);

while (list($key, $val) = each($obj_XML) )
{
	echo $key ." - ";
	if(is_array($val) === true)
	{
		while (list($k, $v) = each($val) )
		{
			echo $k ." - ". $v;
		}
	}
	else
	{
		echo $val;
	}
	echo "
";
}
?>

Expected result:
----------------
@... - type - input
username - Jona

Actual result:
--------------
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input
@... - type - input

etc.


------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=37875&edit=1

#37877 [Bgs->Opn]: 255 char limit for SQL statements

ID: 	      37877
 User updated by:  jr at johnrule dot com
 Reported By:	   jr at johnrule dot com
-Status:	   Bogus
+Status:	   Open
 Bug Type:	   *Database Functions
 Operating System: xp
 PHP Version:	   4.4.2
 New Comment:

The examples have typo's by the way...but the 'theory' is correct.


Previous Comments:
------------------------------------------------------------------------

[2006-06-22 19:35:35] jr at johnrule dot com

Note:

This is not about 'retrieving' data, or limits for data fields, this is
about a limit in executing SQL statements directly through a
COM(ADODB.Connection) to an Access .mdb file.

Example:

INSERT INTO users (first_name, last_name, address, city, state, zip,
username, password) VALUES ('Jonathan', 'Macintyre the 3rd', '123456789
Somewhere in the United States', 'Idaho', 'ID', '12345-12345',
'jonathanmacintyrethe3rd','thisismypassword')

The above command will fail because it is greater than 255 chars. 

The command below will succeed however, using the exact same type of
connection:

INSERT INTO users (fname, lname, address, city, state, zip) VALUES
('Jon', 'Mac', '123 US St.', 'Idaho', 'ID', '12345','jmac','1234')

Do you see what I mean? This is the same limitation imposed if you try
to create a module in Access with a 'RunSQL' command as the
parameter...the field is limited to 255 chars.

However, the first command greater than 255 chars will succeed if you
connect through an ODBC (DSN) connection. I am not sure whose
limitation this is at this point? Since php is making the connection
and call to both, I was guessing that this is a php problem.

------------------------------------------------------------------------

[2006-06-22 19:04:08] tony2001@...

Duplicate of bug #37757.

------------------------------------------------------------------------

[2006-06-21 17:48:51] jr at johnrule dot com

Description:
------------
An 'INSERT' command with more than 255 characters will fail when using
COM and an ADODB.Connection (i.e. a direct connection to an access.mdb
file). However, the command will succeed if you connect through an ODBC
connection to the same file. This would prove that the limitation is not
a part of the file itself, but a part of the functionality of the
interface...wouldn't it?

I tested this on PHP 4 and 5 with the same results:

Apache 2
PHP (4 or 5)
Windows XP

Reproduce code:
---------------
Just try to do an 'INSERT' command with more than 255 characters in it.
It works on an Access.mdb file through a System DSN (ODBC) but it fails
when using COM and ADODB.Connection (i.e. a direct connection to the
file).



------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=37877&edit=1

#37877 [Bgs]: 255 char limit for SQL statements

ID: 	      37877
 User updated by:  jr at johnrule dot com
 Reported By:	   jr at johnrule dot com
 Status:	   Bogus
 Bug Type:	   *Database Functions
 Operating System: xp
 PHP Version:	   4.4.2
 New Comment:

Note:

This is not about 'retrieving' data, or limits for data fields, this is
about a limit in executing SQL statements directly through a
COM(ADODB.Connection) to an Access .mdb file.

Example:

INSERT INTO users (first_name, last_name, address, city, state, zip,
username, password) VALUES ('Jonathan', 'Macintyre the 3rd', '123456789
Somewhere in the United States', 'Idaho', 'ID', '12345-12345',
'jonathanmacintyrethe3rd','thisismypassword')

The above command will fail because it is greater than 255 chars. 

The command below will succeed however, using the exact same type of
connection:

INSERT INTO users (fname, lname, address, city, state, zip) VALUES
('Jon', 'Mac', '123 US St.', 'Idaho', 'ID', '12345','jmac','1234')

Do you see what I mean? This is the same limitation imposed if you try
to create a module in Access with a 'RunSQL' command as the
parameter...the field is limited to 255 chars.

However, the first command greater than 255 chars will succeed if you
connect through an ODBC (DSN) connection. I am not sure whose
limitation this is at this point? Since php is making the connection
and call to both, I was guessing that this is a php problem.


Previous Comments:
------------------------------------------------------------------------

[2006-06-22 19:04:08] tony2001@...

Duplicate of bug #37757.

------------------------------------------------------------------------

[2006-06-21 17:48:51] jr at johnrule dot com

Description:
------------
An 'INSERT' command with more than 255 characters will fail when using
COM and an ADODB.Connection (i.e. a direct connection to an access.mdb
file). However, the command will succeed if you connect through an ODBC
connection to the same file. This would prove that the limitation is not
a part of the file itself, but a part of the functionality of the
interface...wouldn't it?

I tested this on PHP 4 and 5 with the same results:

Apache 2
PHP (4 or 5)
Windows XP

Reproduce code:
---------------
Just try to do an 'INSERT' command with more than 255 characters in it.
It works on an Access.mdb file through a System DSN (ODBC) but it fails
when using COM and ADODB.Connection (i.e. a direct connection to the
file).



------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=37877&edit=1

#37878 [Opn->Asn]: Dom Automatically Replaces ASCII Entities Regardless of substituteEntities

ID: 	      37878
 Updated by:	   tony2001@...
 Reported By:	   brandenrauch at gmail dot com
-Status:	   Open
+Status:	   Assigned
 Bug Type:	   DOM XML related
 Operating System: XP
 PHP Version:	   5.1.4
-Assigned To:	   
+Assigned To:	   rrichards
 New Comment:

Assigned to the maintainer.


Previous Comments:
------------------------------------------------------------------------

[2006-06-21 20:11:06] brandenrauch at gmail dot com

Description:
------------
For my project my data is passing through both xml and xsl. I've chosen
to use decimal (ascII) entities--ex: "--0for input such as quotes
("), singles quotes ('), less thans (<), greater thans(>), and
ampersands (&).

However, when I load my xml into dom it automatically transforms these
characters into either their natural ascII form (specifically quotes),
or an html entity. These transformations are made regardless of the
substituteEntities boolean setting in the DOMDocument object.

Reproduce code:
---------------
$text =
'<tag>"quotes"';

$dom = new DOMDocument();
$dom->substituteEntities = false;

$dom->loadXML($text);

echo $dom->saveHTML();

Expected result:
----------------
<tag>"quotes"

Actual result:
--------------
"quotes"


------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=37878&edit=1

#37893 [Opn->Bgs]: Uncomment any extension in the ini file on windows load warning about module

ID: 	      37893
 Updated by:	   tony2001@...
 Reported By:	   baaron13 at hotmail dot com
-Status:	   Open
+Status:	   Bogus
 Bug Type:	   *Compile Issues
 Operating System: Windows 2003
 PHP Version:	   5.1.4
 New Comment:

Apparently you forgot to update php5ts.dll or some other DLL, which
came with older PHP version.
Not PHP problem.


Previous Comments:
------------------------------------------------------------------------

[2006-06-22 18:38:53] baaron13 at hotmail dot com

Description:
------------
New windows 2003 sp1 box with Microsoft sql 2005 server installed.

Installed PHP 5.1.4 and PECL modules 5.1.4 for windows binary

Everything works fine and my scripts run. But when windows loads I get
the following warning over and over (10 to 20 times)

Unknow(): (null): Unable to intialize module

Module compiled with module API=20050922, debug=0, thread_saftey=1

PHP compiled with module API 20020429, debug=0, thread-saftey=1

If I comment out the extensions in the ini I don't get the message. I
tried just the mssql extension and I GET the error message on windows
load but the module still works.. I can connect to the sql server.

Only changes made to the ini (using the recommended one) are the 
session.save_path  
browscap 
cgi.force_redirect set to 0 
extension_dir

using the isapi



------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=37893&edit=1

#37887 [Opn->Bgs]: My php.ini is not read

ID: 	      37887
 Updated by:	   tony2001@...
 Reported By:	   petrkuzel at eurofins dot com
-Status:	   Open
+Status:	   Bogus
 Bug Type:	   *Configuration Issues
 Operating System: Windows
 PHP Version:	   5.1.4
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.	The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

Put your php.ini to c:\windows and restart web-server.


Previous Comments:
------------------------------------------------------------------------

[2006-06-22 14:54:33] petrkuzel at eurofins dot com

Registry HKEY_LOCAL_MACHINE/SOFTWARE/PHP/IniFilePath works if it points
to folder (vs file as suggested by the name :-(). Again restart.

The remaining issue (for me) is what is SAPI default location and web
server location in case of IIS.

------------------------------------------------------------------------

[2006-06-22 14:35:10] petrkuzel at eurofins dot com

My partial conclusion. 

If phpinfo() states as used php.ini "c:\windows" it in fact does NOT
use any php.ini. 

When is uses php.ini from C:\windows it is reported as
"c:\windows\php.ini"


It would be nice if phpinfo() returned what locations were probed for
the php.ini.

------------------------------------------------------------------------

[2006-06-22 14:29:59] petrkuzel at eurofins dot com

OK it looks like PHP is written in restart whole OS style. After
restarting OS php.ini from C:\windows was picked. I do not undertand
why (there is one in php dir and one pointed by Windows registry key)
but at least I know where to put my php.ini. In spite of fact I hate
it, I can use system global.

Now I can get to point, Mantisbt.org.

------------------------------------------------------------------------

[2006-06-22 14:07:23] petrkuzel at eurofins dot com

I tried to set HKEY_LOCAL_MACHINE/SOFTWARE/PHP/IniFilePath in registry,
but it's also ignored (based on missing the header mark and phpinfo()
output). Still empty result. It's after IIS restart (from IIS console).

------------------------------------------------------------------------

[2006-06-22 13:20:16] petrkuzel at eurofins dot com

Description:
------------
I want to use mssql extension but I'm not able to make PHP use my
php.ini file that contains declaration.

5.1.4 is manually installed on Windows with IIS 5.1. 







Reproduce code:
---------------
"; 

  echo "Prepend = " . ini_get("auto_prepend_file") . "
";

  phpinfo();


  
?>

Expected result:
----------------
Instead of expected:

  INI = c:\app\php  Prepent = c:\app\php\marker.txt

Actual result:
--------------
Returns:

  INI = 
  Prepend = 
   reporting ini path as "c:\windows" (I put there one
with 'auto_prepend_file marker' but it's not picked up), extension_dir
as "c:\php5", consequently no extensions discovered.... 


------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=37887&edit=1

#37870 [Opn->Asn]: Deallocation of prepared statement that hasn't been allocated under postgresql

ID: 	      37870
 Updated by:	   tony2001@...
 Reported By:	   sagi at adamnet dot co dot il
-Status:	   Open
+Status:	   Assigned
 Bug Type:	   PDO related
 Operating System: Debian Sarge
 PHP Version:	   5.1.4
-Assigned To:	   
+Assigned To:	   wez


Previous Comments:
------------------------------------------------------------------------

[2006-06-21 07:52:22] sagi at adamnet dot co dot il

Description:
------------
Using PHP 5.1.4 to connect to a postgresql 8.1.4 database, native
prepared statements.

When allocating a prepared statement and then trying to unset it, PDO
attemps to deallocate it even if it never been used (eg. when running a
query against an empty set).

PDO does not throw an exception in such case, but an error such as:
ERROR:	prepared statement "pdo_pgsql_stmt_085b2f2c" does not exist

Appers in the server log.

When running inside a transaction, such error aborts it.

Reproduce code:
---------------
$pdo->beginTransaction();

$stmt = $pdo->prepare("SELECT 'never executed'");
unset($stmt);

$res = $pdo->query('SELECT 123');


Actual result:
--------------
PHP Fatal error:  Uncaught exception 'PDOException' with message
'SQLSTATE[25P02]: In failed sql transaction: 7 ERROR:  current
transaction is aborted, commands ignored until end of transaction
block' in XXX:13
Stack trace:
#0 XXX: PDO->query('SELECT 123')



------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=37870&edit=1

#37877 [Opn->Bgs]: 255 char limit for SQL statements

ID: 	      37877
 Updated by:	   tony2001@...
 Reported By:	   jr at johnrule dot com
-Status:	   Open
+Status:	   Bogus
 Bug Type:	   *Database Functions
 Operating System: xp
 PHP Version:	   4.4.2
 New Comment:

Duplicate of bug #37757.


Previous Comments:
------------------------------------------------------------------------

[2006-06-21 17:48:51] jr at johnrule dot com

Description:
------------
An 'INSERT' command with more than 255 characters will fail when using
COM and an ADODB.Connection (i.e. a direct connection to an access.mdb
file). However, the command will succeed if you connect through an ODBC
connection to the same file. This would prove that the limitation is not
a part of the file itself, but a part of the functionality of the
interface...wouldn't it?

I tested this on PHP 4 and 5 with the same results:

Apache 2
PHP (4 or 5)
Windows XP

Reproduce code:
---------------
Just try to do an 'INSERT' command with more than 255 characters in it.
It works on an Access.mdb file through a System DSN (ODBC) but it fails
when using COM and ADODB.Connection (i.e. a direct connection to the
file).



------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=37877&edit=1

#37883 [Opn->Bgs]: incorrect handling of double quotes in argv parameters

ID: 	      37883
 Updated by:	   tony2001@...
 Reported By:	   winfried dot pohl at pohl-it dot de
-Status:	   Open
+Status:	   Bogus
 Bug Type:	   CGI related
 Operating System: Windows 2000/2003
 PHP Version:	   5CVS-2006-06-22 (snap)
 New Comment:

Not PHP problem.
Please report it to Microsoft.


Previous Comments:
------------------------------------------------------------------------

[2006-06-22 11:00:01] winfried dot pohl at pohl-it dot de

Description:
------------
php incorrectly handles doubled doublequotes in commandline parameters
which are either ignored or result in messed up argv-array

Reproduce code:
---------------
## test.php


## commandline 1
php test.php """param1_1""param1_2" "param2" "param3"

## commandline 2
php test.php """param1_1""param1_2" "param2" ""


Expected result:
----------------
Array (
  [0] => test.php
  [1] => "param1_1"param1_2
  [2] => param2
  [3] => param3
)

Array (
  [0] => test.php
  [1] => "param1_1"param1_2
  [2] => param2
  [3] => 
)

Actual result:
--------------
Array (
  [0] => test.php
  [1] => "param1_1param1_2 param2 param3
)

Array (
  [0] => test.php
  [1] => "param1_1param1_2 param2 "
)


------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=37883&edit=1

#37891 [Opn->Asn]: memory leak

ID: 	      37891
 Updated by:	   tony2001@...
 Reported By:	   hannes dot magnusson at gmail dot com
-Status:	   Open
+Status:	   Assigned
 Bug Type:	   Scripting Engine problem
 Operating System: FreeBSD
 PHP Version:	   5CVS-2006-06-22 (CVS)
-Assigned To:	   
+Assigned To:	   dmitry


Previous Comments:
------------------------------------------------------------------------

[2006-06-22 18:20:03] hannes dot magnusson at gmail dot com

Description:
------------
Can't seem to get the example any shorter...

Reproduce code:
---------------
backtrace = debug_backtrace();
	call_user_func(array($this, "bar"));
    }
    function bar() {
	array_unshift($this->arr, debug_backtrace());
    }
}

$foo = &new foo;
?>


Actual result:
--------------
/usr/src/clean/php5/Zend/zend_execute.c(403) :	Freeing 
0x082F48E4 (16 bytes), script=/usr/local/php5/....
=== Total 1 memory leaks detected ===



------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=37891&edit=1