Re: [PHP-DB] PDO bindValue ORDER BY
Your workaround is probably what I would do myself.
Note: mysql_real_escape_string() is technically expecting a "string
value", although there is no harm using it, and it's not a bad idea to
avoid possible SQL malicious codes. Alternately, you can also write a
simple function using regular expression to make sure that $sort is
one of your possible sort fields and nothing else.
http://www.tudbc.org
On 11/1/08, Matthew Peltzer <[EMAIL PROTECTED]> wrote:
> ok... this makes more sense now. I know in the past I tried to do
> something similar with table names in the WHERE clause, and that
> didn't work in the same manner.
>
> Is there a better way to do what I'm trying to do? that is, sorting
> within the SQL statement based on a supplied column name without out
> writing multiple SQL statements?
>
> for now my work around is to some thing like:
>
> $sort = mysql_real_escape_string($sort);
> $sql = "SELECT * FROM `table` ORDER BY `$sort`";
>
> which makes me queasy because I spent a lot of time getting away from
> inlining variables in SQL statements.
>
>
>
> On Fri, Oct 31, 2008 at 6:46 PM, Post TUDBC <[EMAIL PROTECTED]> wrote:
> > Technically, bound parameter is expecting a value, such as
> >WHERE ID=:id
> > However, ORDER BY is followed by a field name, such as
> > ORRDER BY ID
> > So I don't think it should work.
> >
> > If it does work, then it is a sign that the database driver is not
> > really preparing the statement (as it should for performance reason),
> > but it is just substituiting values to compose a SQL (just for your
> > convenience).
> >
> > On 10/31/08, Matthew Peltzer <[EMAIL PROTECTED]> wrote:
> >> Are pdo bound parameters within an ORDER BY clause broken in php 5.2.5?
> >>
> >> I find that in php 5.2.6 this works as expected:
> >>
> >>>> $sql = 'SELECT * FROM `table` ORDER BY :sort';
> >> $stmt = $pdo->prepare($sql);
> >> $stmt->bindValue(':sort', $sort, PDO::PARAM_STR);
> >> $stmt->execute();
> >> print_r($stmt->fetchAll(PDO::FETCH_ASSOC));
> >> ?>
> >>
> >> but under php5.2.5 the ORDER BY clause silently fails. Also,
> >> parameters bound to SELECT or WHERE or LIMIT clauses function
> >> correctly, but ORDE BY still has no effect. If I remove the
> >> "$stmt->bindValue(':sort', $sort, PDO::PARAM_STR);" line or the "ORDER
> >> BY :sort" I get a "number of bound variables does not match number of
> >> tokens" error.
> >>
> >> So it appears the parsing mechanism is funcitoning, but what ever is
> >> responsible for binding to ORDER BY is not.
> >>
> >> I've looked in bug reports and the change logs, but did not find a
> >> explicit reference to this issue.
> >>
> >>
> >> --
> >> -- Matthew Peltzer
> >> -- [EMAIL PROTECTED]
> >>
> >>
> >> --
> >> PHP Database Mailing List (http://www.php.net/)
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >
>
>
>
>
> --
>
> -- Matthew Peltzer
> -- [EMAIL PROTECTED]
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] PDO bindValue ORDER BY
Technically, bound parameter is expecting a value, such as
WHERE ID=:id
However, ORDER BY is followed by a field name, such as
ORRDER BY ID
So I don't think it should work.
If it does work, then it is a sign that the database driver is not
really preparing the statement (as it should for performance reason),
but it is just substituiting values to compose a SQL (just for your
convenience).
On 10/31/08, Matthew Peltzer <[EMAIL PROTECTED]> wrote:
> Are pdo bound parameters within an ORDER BY clause broken in php 5.2.5?
>
> I find that in php 5.2.6 this works as expected:
>
>$sql = 'SELECT * FROM `table` ORDER BY :sort';
> $stmt = $pdo->prepare($sql);
> $stmt->bindValue(':sort', $sort, PDO::PARAM_STR);
> $stmt->execute();
> print_r($stmt->fetchAll(PDO::FETCH_ASSOC));
> ?>
>
> but under php5.2.5 the ORDER BY clause silently fails. Also,
> parameters bound to SELECT or WHERE or LIMIT clauses function
> correctly, but ORDE BY still has no effect. If I remove the
> "$stmt->bindValue(':sort', $sort, PDO::PARAM_STR);" line or the "ORDER
> BY :sort" I get a "number of bound variables does not match number of
> tokens" error.
>
> So it appears the parsing mechanism is funcitoning, but what ever is
> responsible for binding to ORDER BY is not.
>
> I've looked in bug reports and the change logs, but did not find a
> explicit reference to this issue.
>
>
> --
> -- Matthew Peltzer
> -- [EMAIL PROTECTED]
>
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] MySQL stored procedures OUT or INOUT parameters
TUDBC has recently moved to open-source GPL, similar to how MySQL works. (You probably got the impression that it had proprietary license, maybe because some the obsolete webpages still referred to the old license, so I have corrected those obsolete web pages.) I am not familiar with FOSS, but my reading showed that GPL is the most used open-source license, which was why I chose GPL. On 10/11/08, Tim Hawkins <[EMAIL PROTECTED]> wrote: > Until TUDBC is available under an accredited FOSS license, nobody in their > right mind is going to use it in any project that > may need to be ipr encumbrement free at a future date. > > Posting solutions that pertain to a proprietary technology on a list > predominately dedicated to technologies that do meet that > requirement is bordering on being classified as commercial spam. > > On 11 Oct 2008, at 01:52, Post-No-Reply TUDBC wrote: > > > > I kindly disagree. The original post asked "How to use OUT or INOUT > > parameters of MySQL's stored procedures in PHP?" by STF. > > > > To quote STF again in a later post "Yes, I've already found that > > multi-step way before... I was just wondering if anything got better > > since with regard to this. Apparently not." > > > > If you're aware of what developers need to face when dealing with when > > trying to get an OUT parameter from a stored procedure, there are > > multi-step way workaround which is cumbersome. > > > > My reply is directly offering an alternate way in PHP to solve this > > problem faced by the original post. > > > > > > On 10/10/08, Fergus Gibson <[EMAIL PROTECTED]> wrote: > > > > > 2008/10/10 Post-No-Reply TUDBC <[EMAIL PROTECTED]>: > > > > > > > > > > By using TUDBC (http://www.tudbc.org), you can call stored procedures > > > > easily. > > > > > > > > > > > > > Your post was an excellent answer to the question, "How do I call > > > stored procedures easily with TUDBC?" Unfortunately, that is not what > > > the original poster asked. In fact, no one has ever asked that > > > question on this list. Ever. Posting to the list from a generic > > > "no-reply" address seems pretty rude. > > > > > > But setting aside the irrelevance of your post, the example does not > > > seem "EZ" at all. In fact, it seems quite a bit more complicated than > > > the comparable code for PDO or mysqli, not to mention both > > > unnecessarily verbose and simultaneously cryptic. > > > > > > > > > -- > > > > > > PHP Database Mailing List (http://www.php.net/) > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > > > > -- > > PHP Database Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
