<quote>
If search and replace are arrays, then str_replace() takes a value from
each array and uses them to search and replace on subject. If replace has
fewer values than search, then an empty string is used for the rest of
replacement values. If search is an array and replace is a string, then
this replacement string is used for every value of search. The converse
would not make sense, though.
</quote>

On 6/19/2014 7:33 PM, richard wrote:> $a=str_replace($a,"\","");> > This generates the error: Unexpected "".> > http://www.php.net//manual/en/function.str-replace.php> > While here in the manual, they do precisely the same thing!> > <quote>> If search and replace are arrays, then str_replace() takes a value from> each array and uses them to search and replace on subject. If replace has> fewer values than search, then an empty string is used for the rest of> replacement values. If search is an array and replace is a string, then> this replacement string is used for every value of search. The converse> would not make sense, though. > </quote>>

Note that "search" is the first parameter, "replace" is the second,
and "subject" is the third.

So, your
str_replace($a,"\","");
will return a string or array with all occurrences of
the contents of $a
in
""
with the given
"\"
value

What you apparently want is
str_replace("\","",$a);

> <quote>> If search and replace are arrays, then str_replace() takes a value from> each array and uses them to search and replace on subject. If replace has> fewer values than search, then an empty string is used for the rest of> replacement values. If search is an array and replace is a string, then> this replacement string is used for every value of search. The converse> would not make sense, though.> </quote>

--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

On 6/19/2014 8:11 PM, Lew Pitcher wrote:> On Thursday 19 June 2014 19:33, in comp.lang.php, "richard"> <noreply(at)example(dot)com> wrote:> >> $a=str_replace($a,"\","");>> >> This generates the error: Unexpected "".> > Of course it does. You are trying to replace all the strings that match $a> with "\" in an empty string ("").> >> http://www.php.net//manual/en/function.str-replace.php>> >> While here in the manual, they do precisely the same thing!> > To quote the webpage:> # str_replace — Replace all occurrences of the search string with the> # replacement string > # Description> # mixed str_replace ( mixed $search , mixed $replace , mixed $subject > # [, int &$count ] ) > # > # This function returns a string or an array with all occurrences of search> # in subject replaced with the given replace value. > > Note that "search" is the first parameter, "replace" is the second,> and "subject" is the third.> > So, your > str_replace($a,"\","");> will return a string or array with all occurrences of> the contents of $a> in> ""> with the given> "\"> value> > > What you apparently want is> str_replace("\","",$a);> >> <quote>>> If search and replace are arrays, then str_replace() takes a value from>> each array and uses them to search and replace on subject. If replace has>> fewer values than search, then an empty string is used for the rest of>> replacement values. If search is an array and replace is a string, then>> this replacement string is used for every value of search. The converse>> would not make sense, though.>> </quote>> >

> richard, 2014-06-20 01:33:> >> $a=str_replace($a,"\","");>> >> This generates the error: Unexpected "".>> >> http://www.php.net//manual/en/function.str-replace.php>> >> While here in the manual, they do precisely the same thing!> > No - they don't!> > Use: $a=str_replace($a,"\"","");

Sorry - of course: $a=str_replace("\"","",$a);

Since the order of the parameters is

1) What to search
2) What to replace
3) Where to search in

> Beware of the double quotes, since \ starts an escape - this means, the> meaning of the second quote (") is NOT "end string here".> > To make this more clear:> > > " <- String starts here. \" <- This just ONE character end here -> "

On 6/19/2014 9:21 PM, Arno Welzel wrote:> Arno Welzel, 2014-06-20 03:19:> >> richard, 2014-06-20 01:33:>> >>> $a=str_replace($a,"\","");>>> >>> This generates the error: Unexpected "".>>> >>> http://www.php.net//manual/en/function.str-replace.php>>> >>> While here in the manual, they do precisely the same thing!>> >> No - they don't!>> >> Use: $a=str_replace($a,"\"","");> > Sorry - of course: $a=str_replace("\"","",$a);> > Since the order of the parameters is> > 1) What to search > 2) What to replace> 3) Where to search in> >> Beware of the double quotes, since \ starts an escape - this means, the>> meaning of the second quote (") is NOT "end string here".>> >> To make this more clear:>> >> >> " <- String starts here. \" <- This just ONE character end here -> "> >

Arno, that will replace the double quotes ("), which doesn't look like
what Richard wants.

But why help him when all he does is insult the same people who try to
help him? That's exactly why I didn't just give him the answer in the
first place (not to mention the fact he's asked similar questions
before, and has still failed to learn).

There is a reason that you have been advised in the past to use certain
functions and best practices instead of trying to reinvent them yourself.
This is just another example of your persistent refusal to listen to good
advice biting your arse.

> On 6/19/2014 9:21 PM, Arno Welzel wrote:>> Arno Welzel, 2014-06-20 03:19:>> >>> richard, 2014-06-20 01:33:>>> >>>> $a=str_replace($a,"\","");>>>> >>>> This generates the error: Unexpected "".>>>> >>>> http://www.php.net//manual/en/function.str-replace.php>>>> >>>> While here in the manual, they do precisely the same thing!>>> >>> No - they don't!>>> >>> Use: $a=str_replace($a,"\"","");>> >> Sorry - of course: $a=str_replace("\"","",$a);>> >> Since the order of the parameters is>> >> 1) What to search >> 2) What to replace>> 3) Where to search in>> >>> Beware of the double quotes, since \ starts an escape - this means, the>>> meaning of the second quote (") is NOT "end string here".>>> >>> To make this more clear:>>> >>> >>> " <- String starts here. \" <- This just ONE character end here -> ">> >> > > Arno, that will replace the double quotes ("), which doesn't look like> what Richard wants.

Well - I don't know, what Richard really wants. If it was about removing
backslashes:

$a=str_replace("\\","",$a);

> But why help him when all he does is insult the same people who try to> help him? That's exactly why I didn't just give him the answer in the> first place (not to mention the fact he's asked similar questions> before, and has still failed to learn).

I don't want to give newbies the impression, that Richard knows, what he
is writing about, when he claims that things he does are exactly shown
like that in the PHP manual ;-)

> richard, 2014-06-20 01:33:> >> $a=str_replace($a,"\","");>> >> This generates the error: Unexpected "".>> >> http://www.php.net//manual/en/function.str-replace.php>> >> While here in the manual, they do precisely the same thing!> > No - they don't!> > Use: $a=str_replace($a,"\"","");> > Beware of the double quotes, since \ starts an escape - this means, the> meaning of the second quote (") is NOT "end string here".> > To make this more clear:> > > " <- String starts here. \" <- This just ONE character end here -> "

That could be the problem as some times the \ shows and some times it
doesn't.
I've tried several combinatiosn, still the \ remains.

As for the technically correct proper order it is
search, replace, subject.

On 6/19/2014 10:06 PM, Arno Welzel wrote:> Jerry Stuckle, 2014-06-20 03:33:> >> On 6/19/2014 9:21 PM, Arno Welzel wrote:>>> Arno Welzel, 2014-06-20 03:19:>>> >>>> richard, 2014-06-20 01:33:>>>> >>>> > $a=str_replace($a,"\","");>>>> >>>>> > This generates the error: Unexpected "".>>>> >>>>> > http://www.php.net//manual/en/function.str-replace.php>>>> >>>>> > While here in the manual, they do precisely the same thing!>>>> >>>> No - they don't!>>>> >>>> Use: $a=str_replace($a,"\"","");>>> >>> Sorry - of course: $a=str_replace("\"","",$a);>>> >>> Since the order of the parameters is>>> >>> 1) What to search >>> 2) What to replace>>> 3) Where to search in>>> >>>> Beware of the double quotes, since \ starts an escape - this means, the>>>> meaning of the second quote (") is NOT "end string here".>>>> >>>> To make this more clear:>>>> >>>> >>>> " <- String starts here. \" <- This just ONE character end here -> ">>> >>> >> >> Arno, that will replace the double quotes ("), which doesn't look like>> what Richard wants.> > Well - I don't know, what Richard really wants. If it was about removing> backslashes:> > $a=str_replace("\\","",$a);> >> But why help him when all he does is insult the same people who try to>> help him? That's exactly why I didn't just give him the answer in the>> first place (not to mention the fact he's asked similar questions>> before, and has still failed to learn).> > I don't want to give newbies the impression, that Richard knows, what he> is writing about, when he claims that things he does are exactly shown> like that in the PHP manual ;-)> >

I don't think even newbies would consider richard knows what he's doing
here...

> On Thursday 19 June 2014 19:33, in comp.lang.php, "richard"> <noreply(at)example(dot)com> wrote:> >> $a=str_replace($a,"\","");>> >> This generates the error: Unexpected "".> > Of course it does. You are trying to replace all the strings that match $a> with "\" in an empty string ("").

> On Fri, 20 Jun 2014 03:19:53 +0200, Arno Welzel wrote:> >> richard, 2014-06-20 01:33:>> >>> $a=str_replace($a,"\","");>>> >>> This generates the error: Unexpected "".>>> >>> http://www.php.net//manual/en/function.str-replace.php>>> >>> While here in the manual, they do precisely the same thing!>> >> No - they don't!>> >> Use: $a=str_replace($a,"\"","");>> >> Beware of the double quotes, since \ starts an escape - this means, the>> meaning of the second quote (") is NOT "end string here".>> >> To make this more clear:>> >> >> " <- String starts here. \" <- This just ONE character end here -> "> > That could be the problem as some times the \ shows and some times it> doesn't.> I've tried several combinatiosn, still the \ remains.> > As for the technically correct proper order it is> search, replace, subject.

Indeed it is. But that's not what you're doing. And that's why it doesn't work.

a) You need to learn to read the documentation syntax order properly, $a
goes at the end, not the start.

b) Just because you find a hammer, everything doesn't become a nail.
Please try and use the RIGHT tool for the job. Do not mindlessly expect
silver bullets to appear, especially while looking down a barrel. Do
some proper research for yourself first.

> On Fri, 20 Jun 2014 03:19:53 +0200, Arno Welzel wrote:> >> richard, 2014-06-20 01:33:>> >>> $a=str_replace($a,"\","");>>> >>> This generates the error: Unexpected "".>>> >>> http://www.php.net//manual/en/function.str-replace.php>>> >>> While here in the manual, they do precisely the same thing!>> >> No - they don't!>> >> Use: $a=str_replace($a,"\"","");>> >> Beware of the double quotes, since \ starts an escape - this means, the>> meaning of the second quote (") is NOT "end string here".>> >> To make this more clear:>> >> >> " <- String starts here. \" <- This just ONE character end here -> "> > That could be the problem as some times the \ shows and some times it> doesn't.> I've tried several combinatiosn, still the \ remains.> > As for the technically correct proper order it is> search, replace, subject.

> richard, 2014-06-20 04:13:> >> On Fri, 20 Jun 2014 03:19:53 +0200, Arno Welzel wrote:>> >>> richard, 2014-06-20 01:33:>>> >>>> $a=str_replace($a,"\","");>>>> >>>> This generates the error: Unexpected "".>>>> >>>> http://www.php.net//manual/en/function.str-replace.php>>>> >>>> While here in the manual, they do precisely the same thing!>>> >>> No - they don't!>>> >>> Use: $a=str_replace($a,"\"","");>>> >>> Beware of the double quotes, since \ starts an escape - this means, the>>> meaning of the second quote (") is NOT "end string here".>>> >>> To make this more clear:>>> >>> >>> " <- String starts here. \" <- This just ONE character end here -> ">> >> That could be the problem as some times the \ shows and some times it>> doesn't.>> I've tried several combinatiosn, still the \ remains.>> >> As for the technically correct proper order it is>> search, replace, subject.> > No - it isn't - READ:> > <http://www.php.net//manual/en/function.str-replace.php>> > > str_replace ( $search , $replace , $subject [, int &$count ] )> > This function returns a string or an array with all occurrences of> search in subject replaced with the given replace value.

Sorry... Richard is really confusing to read sometimes - since he did
read the manual but did not use it...

Good point! However, the need for removing backslashes begs the
question where these backslashes come from in the first place. I
suppose the cause is <news:itrvizyykmyu$(dot)1m8xc48h8xvgi(dot)dlg(at)40tude(dot)net>:

> Geoff Muldoon wrote:> >> In article <1kcemjreijezv$(dot)k2q3x4bl6eoc(dot)dlg(at)40tude(dot)net>,>> noreply(at)example(dot)com says...>> >>> $a=str_replace($a,"\","");>> >> c) Google PHP stripslashes.> > Good point! However, the need for removing backslashes begs the> question where these backslashes come from in the first place. I> suppose the cause is <news:itrvizyykmyu$(dot)1m8xc48h8xvgi(dot)dlg(at)40tude(dot)net>:> > | $a=str_replace("'","\'",$a);> | Works just fine.> > So much for "works just fine".

As I said upthread, to richard:

There is a reason that you have been advised in the past to use certain
functions and best practices instead of trying to reinvent them yourself.
This is just another example of your persistent refusal to listen to good
advice biting your arse.

b) On certain platforms (perhaps on Oracle more so than MySQL, etc.) the
ability to shared pool cache or soft-parse rather than hard-parse a
particular execution plan, often significantly increasing performance
when querying the same columns from the sames tables.

On 6/22/2014 7:20 PM, Geoff Muldoon wrote:> jstucklex(at)attglobal(dot)net says...> >>> Of course, bind variables are massively better, but I doubt that > Richard >>> is up to knowing about them yet.> >> One opinion. But bound values have their problems, also. They are>> neither better nor worse than properly escaping values. Just another>> way of doing things.> > Hmm, I've never really found any signifcant down-side to using bind > variables if they are used corrctly, so I'd appreciate any links you > might have.> > IMHO three of the main pluses are:> > a) A strong (but not totally foolproof) barrier against SQL injection > attacks.> > b) On certain platforms (perhaps on Oracle more so than MySQL, etc.) the > ability to shared pool cache or soft-parse rather than hard-parse a > particular execution plan, often significantly increasing performance > when querying the same columns from the sames tables.> > c) Parameter input values do not NEED to be properly escaped.> > http://en.wikipedia.org/wiki/Prepared_statement> > GM>

Performance, for one. Bound values require at least one extra call to
the libraries (for the PREPARE).

Additional calls are required to bind numeric values. Of course they
are also required for string variables, but since strings need to
otherwise be processed through mysql_real_escape_string(), that's a push.

Additionally, values should always be validated before being used in a
mysql request anyway.

The extra processing can be excessive in a busy site. Of course, if
you're only getting 100 hits/day, it's not a problem.

> The extra processing can be excessive in a busy site. Of course, if> you're only getting 100 hits/day, it's not a problem.

Yes, the first usage of a prepared statement will always require that
extra call, and if it is a query that is unlikely to be run again before
it is flushed from the cache, it will require this call again each time.

However, *particularly if it IS a busy site* and it is a query that is
likely to be executed with a very high regularity (e.g.: "select <fixed
list of order details columns> from order_details_table where order_id =
:<bound variable>") then the benefit of SQL execution plan caching and
soft instead of hard parsing will usually *massively* outweigh that
possible initial overhead.

High-volume sites are MORE likely than toy ones to benefit from bind
variables.

On 6/23/2014 2:33 AM, Geoff Muldoon wrote:> jstucklex(at)attglobal(dot)net says...>> >> On 6/22/2014 7:20 PM, Geoff Muldoon wrote:>>> jstucklex(at)attglobal(dot)net says...> >>> Hmm, I've never really found any signifcant down-side to using bind >>> variables if they are used corrctly, so I'd appreciate any links you >>> might have.> >> Performance, for one. Bound values require at least one extra call to>> the libraries (for the PREPARE).> >> The extra processing can be excessive in a busy site. Of course, if>> you're only getting 100 hits/day, it's not a problem.> > Yes, the first usage of a prepared statement will always require that > extra call, and if it is a query that is unlikely to be run again before > it is flushed from the cache, it will require this call again each time. > > However, *particularly if it IS a busy site* and it is a query that is > likely to be executed with a very high regularity (e.g.: "select <fixed > list of order details columns> from order_details_table where order_id = > :<bound variable>") then the benefit of SQL execution plan caching and > soft instead of hard parsing will usually *massively* outweigh that > possible initial overhead.> > High-volume sites are MORE likely than toy ones to benefit from bind > variables.> > GM>

If it's a busy site, then there will be a lot more calls to MySQL - and
chances are the cache will be filled (and flushed) before the prepared
statement is run again. It's not how long since the query has run -
it's how many other queries have been run. Remember it isn't just one
query being run on a site - a large site will have hundreds (or more)
different queries.

And it will still require a call each time, because you never know
whether it has been flushed or not.

Additionally, you ignore the fact additional calls need to be made to
bind numeric values - calls which are not required when not using bind
values.

Have you ever worked on a high-active site? Say 1K hits/second or more?
And have you ever profiled bind values on such a site? I have. Bind
values are significantly slower.

jstucklex(at)attglobal(dot)net says...> Have you ever worked on a high-active site? Say 1K hits/second or
more?> And have you ever profiled bind values on such a site? I have.

Most high-activity sites I've worked on have used Oracle rather than
MySQL, and Oracle is much better at targetting and maintaining bind
variable execution plans in cache. You may be right that MySQL gains
less and could suffer more from using them.

Additionally, just because a site has high volumes that doesn't
necessarily mean lots of different SQL statements. I've worked on very
high volume sites where 80+% of the database calls are made using less
than 10 different queries - find a product, add product to order
(looping), show an order, write an invoice, etc. In these cases, with
correct cache size tweaking, performace was substantially improved by
using bind variables.

On 6/23/2014 10:34 PM, Geoff Muldoon wrote:> jstucklex(at)attglobal(dot)net says...>> Have you ever worked on a high-active site? Say 1K hits/second or > more?>> And have you ever profiled bind values on such a site? I have. > > Most high-activity sites I've worked on have used Oracle rather than > MySQL, and Oracle is much better at targetting and maintaining bind > variable execution plans in cache. You may be right that MySQL gains > less and could suffer more from using them. > > Additionally, just because a site has high volumes that doesn't > necessarily mean lots of different SQL statements. I've worked on very > high volume sites where 80+% of the database calls are made using less > than 10 different queries - find a product, add product to order > (looping), show an order, write an invoice, etc. In these cases, with > correct cache size tweaking, performace was substantially improved by > using bind variables.> > GM>

It depends on the site. I've also used Oracle on websites (as well as
DB2 and SQL Server). Results vary quite a bit.

I've never seen a site where 80+% of the database calls are made with
less than 10 different queries. But then the sites I've worked on are
typically pretty complicated sites - not simple shopping carts. If all
you're doing is a shopping cart, then I can see where bind variables
might help.

But just because you find something works better in Oracle doesn't mean
it works better in MySQL. I find a lot of things work better in DB2,
for instance, than either Oracle or MySQL (try doing recursive SQL in
MySQL, for instance).

[...]> Additionally, just because a site has high volumes that doesn't > necessarily mean lots of different SQL statements.

I would argue just the opposite, in fact -- the higher the volume, the more likely that a large
number of SQL statements are substantially the same.

> I've worked on very > high volume sites where 80+% of the database calls are made using less > than 10 different queries - find a product, add product to order > (looping), show an order, write an invoice, etc. In these cases, with > correct cache size tweaking, performace was substantially improved by > using bind variables.

On 6/24/2014 7:12 AM, Doug Miller wrote:> Geoff Muldoon <geoff(dot)muldoon(at)trap(dot)gmail(dot)com> wrote in news:MPG.2e138ecff04eddb9d1> @news.albasani.net:> > [...]>> Additionally, just because a site has high volumes that doesn't >> necessarily mean lots of different SQL statements. > > I would argue just the opposite, in fact -- the higher the volume, the more likely that a large > number of SQL statements are substantially the same.> >> I've worked on very >> high volume sites where 80+% of the database calls are made using less >> than 10 different queries - find a product, add product to order >> (looping), show an order, write an invoice, etc. In these cases, with >> correct cache size tweaking, performace was substantially improved by >> using bind variables.> > Exactly so.>

The number of SQL statements is not based on the volume; rather it is
based on what the site does. If all you have is a shopping cart, the
number of SQL statements is going to be low. Other sites have a much
larger number of SQL statements.

Pointed"YMMD"Ears
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(at)news(dot)demon(dot)co(dot)uk>