Hi,

a very dirty workaround is to download the wsdl an rewrite it locally to another datatype. Changing this line:

<xs:element name="id" type="xs:long"></xs:element>

to

<xs:element name="id" type="xs:float"></xs:element>

should work at least. But it's a very, very, VERY, VERY, VEWY, VEWY, VEWYVEWYVEWY dirty workaround and you'll got to hell for this or even worse!

Sorry, this one is way toooo dirty.

I have the same problem ( http://bugs.php.net/bug.php?id=49669 ) but float replacement not working!

I can not reproduce it with PHP 5.2 HEAD. Can you check with a sniffer, or with __getLastRequest/Response if the error also occurs in the request?

I am not pro in SOAP so maybe provide me __getLastRequest/Response testing code?

another note:
I get corrent result sends from a server using PHP 5.2.42
Incorrect result sends from a server with PHP 5.2.9

Hi,

in the meantime my company upgraded to 5.2.11 (security reasons); the bug seems to be in there, too.

Unluckily updating to HEAD is no option, since we are using the ZendPlatform.

Regs
  Rob

I experience a similar issue on latest FreeBSD+Apache-2.2.13+PHP5.2.11 whiling passing longint to a postgresql. When passing a number larger then maxint, it's reduced to 2147483647.

To properly diagnose this bug, we need the SOAP request and response. You can get that using a sniffer (Wireshark) or using __getLastRequest and __getLastResponse. See the PHP manual for information on these methods.

Hey guys,

this serious bug is still damaging SOAP envelopes with long in there. We have the same problem on PHP 5.3.2 and 5.3.3 (32Bit) under Windows 2008R2 (64Bit) with IIS7. I think the bug reporter posted exactly the last request in order to fix this issue. Here is ours:

<SOAP-ENV:Envelope xmlns:SOAP-ENV=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:ns1=\"http://rsp.soap.atlas.jungheinrich.de/\">
	<SOAP-ENV:Body>
		<ns1:sendConfigurationData>
			<arg0>
				<ffzId>96D</ffzId>
				<gatewayIds>3B27DE81</gatewayIds>
		    </arg0>
			<arg1>
				<header>
					<options>2147483647</options>
					<messageId>36</messageId>
					<created>2010-10-27T16:54:19</created>
					<expires>1970-01-01T01:00:00</expires>
					<deviceId>96D</deviceId>
					<formatRevision>0</formatRevision>
				</header>
			</arg1>
		</ns1:sendConfigurationData>
	</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

I believe that it is time to fix this loooong problem with long datatypes.

My 2 cents

Periklis

PHP on windows uses 32bit integer for long, always. That's not possible to fix easily either.

Two choices, either convert to double when an integer overflow happens, or wait until we have big integer support.

Ouch... Pierre, 

one serious notice is, that we changed the wsdl for <options> from xsd:long to xsd:string and the problem is still there. Do we have here an auto-casting from string to long?

Any ideas?

try:

$a = "1234";
$b = 1234;

if ($a == $b) echo "hopla";

well known problem related to php auto casting, or better said, typeless.

PHP 5.5.12 x86 on Windows 8 and it's still there. Thankfully the workaround in the comment #1 works for me. Thank you "ghostbaer at gmx dot de", you saved my work.

Even if you pass a huge integer as a string it is mixed up.

Reason: PHP 5.6.23, file ext/soap/php_encoding.c, function to_xml_long:

Line 1118:

                if (Z_TYPE(tmp) != IS_LONG) {
                        convert_to_long(&tmp);
                }
                convert_to_string(&tmp);

If a string is passed, it should not be converted to long and back to string loosing precision with very long integers.

Simple Fix:

In ext/soap/php_encoding.c, in all lines containing

  XSD_...INTEGER

i.e. for all XML data types containing integers of unlimited size,
replace "long" with "string", e.g.

        {{XSD_INTEGER, XSD_INTEGER_STRING, XSD_NAMESPACE, NULL}, to_zval_long, to_xml_long},

becomes

        {{XSD_INTEGER, XSD_INTEGER_STRING, XSD_NAMESPACE, NULL}, to_zval_string, to_xml_string},

This fix brings a minor incompatibility if somebody checks value and type of the result of a SOAP function.
(An alternative would be to add a function to_zval_long_or_string that returns an integer if it fits and otherwise a string.)