On Thu, Mar 5, 2009 at 12:00 PM, haliphax <haliphax@xxxxxxxxx> wrote:
> On Thu, Mar 5, 2009 at 10:52 AM, Eric Butera <eric.butera@xxxxxxxxx> wrote:
>> On Thu, Mar 5, 2009 at 11:16 AM, Nigel Green <nigel@xxxxxxxxxxxxxx> wrote:
>>> Hi all,
>>>
>>> This is my first post to the list. Have been observing for a few weeks and
>>> have learnt a lot.
>>>
>>> I am having an issue in one of my scripts where using the
>>> mysql_real_escape_string function is stripping content out of my input data.
>>> All is working well on my local installation, but when the files are
>>> transferred over to the live site I am getting problems.
>>>
>>> The sample code I am using to test this is as follows:
>>>
>>> if(isset($this->mysql)) {
>>> $query = "update pages set";
>>> $query .= " `title` = '" . mysql_real_escape_string ($title) . "',";
>>> $query .= " `text` = '" . mysql_real_escape_string ($text) . "',";
>>> $query .= " where id = \"$id\"";
>>> }
>>> echo $query;
>>>
>>> The $title, $text and $id values are passed in as parameters when I call the
>>> method that runs the update, and if I echo them out at the top of the method
>>> they are all present and correct.
>>>
>>> The $mysql class variable is populated with a connection handle when I
>>> instantiate an instance of the class, and the code is finding the connection
>>> as it is building the query. On my local machine the query is built using
>>> the escaped values from the $_POST array, but on the live site the escaped
>>> values for $title and $text are blank.
>>>
>>> Any ideas on where to look for config differences? The main thing I've found
>>> so far is that this may happen if no connection is present, but it is. Doing
>>> a var_dump of the connection handle shows that it is the correct handle as
>>> well.
>>>
>>> Any thoughts?
>>>
>>> Many thanks in advance for any help.
>>>
>>> Nigel
>>>
>>
>> Make sure to always pass your active database connection into the
>> second parameter of mysql_real_escape_string. There could be
>> character set differences between your two servers too that might be
>> causing issues for you. If at all possible I would recommend
>> upgrading to mysqli or pdo and use prepared statements.
>
> mysqli may not be available to him (PHP4, etc.) and I don't see why he
> should completely switch his procedure if his code will work with the
> addition of the db handle in the function call... but that's my 2c. I
> agree that at some level, it is more beneficial to change all of the
> code you have to use a new method/construct/whatever, but it may not
> be worth it in his case.
>
>
> // Todd
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Using php4 is beyond irresponsible at this point.
--
http://www.voom.me | EFnet: #voom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
