Hm.  So your solution is "don't use LIKE"?  I can't say I'm wild about that. :-/

--Larry Garfield

On Mon, 4 Aug 2008 15:49:52 -0400, "Adam Richardson" <[EMAIL PROTECTED]> wrote:
> Larry,
> 
> I agree that having to escape values in a stored procedure does run
> counter
> to expectations.  It's likely other developers have the potential for
> short-circuiting their LIKE conditions without realizing it.
> 
> I've dealt with this issue, too, and haven't been especially pleased with
> any of the solutions I've undertaken.  Recently, I've been avoiding LIKE
> conditions and using INSTR, LOCATE, CHARINDEX, etc. to avoid the potential
> for unescaped wildcards.
> 
> Adam
> 
> On Mon, Aug 4, 2008 at 12:33 PM, Larry Garfield
> <[EMAIL PROTECTED]>wrote:
> 
>>
>> On Mon, 4 Aug 2008 11:48:39 -0400, "Andrew Ballard" <[EMAIL PROTECTED]>
>> wrote:
>> > On Mon, Aug 4, 2008 at 11:35 AM, Larry Garfield
> <[EMAIL PROTECTED]>
>> > wrote:
>> >>
>> >> On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen <[EMAIL PROTECTED]>
>> wrote:
>> >>> Larry Garfield wrote:
>> >>>
>> >>>> IIRC, the way in SQL to circumvent that is to convert "100%" into
>> >>>> "100%%". However, that does rather defeat the purpose of a prepared
>> >>>> statement if I have to do my own escaping anyway, does it not?=20
>> >>>
>> >>> Depends on what you perceive the purpose of the prepared statement
> to
>> >>> be :-)  In this context, I tend to think of performance only.  Which
>> > is=
>> >>>
>> >>> generally why I can't be bothered with prepared statements in
> php.=20
>> >>
>> >> Actually in most cases in PHP you don't get much performance.  What
> you
>> > do get is added security, because prepared statements are cleaner than
>> > cleaner and more reliable than string escaping.  Of course, then we
> run
>> > into the % problem above.


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to