I was about to say that the only semantic I'm aware of for hex'25' in an IBM Midrange EBCDIC context is as the 5250 attribute code for dim underlined reverse-image.

Then I remembered passing hex'0D25' to things like HTTPAPI and MMAIL.

But given that hex'0A' has been entrenched in the application for over two decades, changing the application is not an option.

Where the prepared-statement version has
$temp = "Name: " . $name . "
Email Address: " . $emailAddress . "
Phone Number: " . $phoneNumber . "
Message: " . $message . "
HTTP_REFERRER: " . $_SERVER[ 'HTTP_REFERER' ]; // Notes
$nnotes = str_replace( " ", "", $temp );
which then gets passed as a paramter in the prepared statement,

the non-prepared-statement version has

$nnotes = " 'Name: " . $name . "' || x'0A' ||
'Email Address: " . $emailAddress . "' || x'0A' ||
'Phone Number: " . $phoneNumber . "' || x'0A' ||
'Message: " . $message . "' || x'0A' ||
'HTTP_REFERRER: " . $_SERVER[ 'HTTP_REFERER' ] . "' "; // Notes

Which probably explains the difference in behavior.

Either the prepared-statement version has to behave like the non-prepared-statement version, or they have to stick with the non-prepared-statement version.

--
JHHL

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.