: SQL_CALC_FOUND_ROWS using ODBC driver
Hi,
I've used PHP with MySQL and I was able to count the rows of a table by
using the following code:
SELECT SQL_CALC_FOUND_ROWS * FROM MyTableName; SELECT FOUND_ROWS();
However, I would like to do the same thing using Visual Basic 6...
When I set the RS.Source t
Nils Meyer wrote:
SELECT
SQL_CALC_FOUND_ROWS doesn't make much sense without a where clause by
the way.
LIMIT, not where.
Thanks for the reply... That seems to make sense. I'm talking about the part
of one record being returned containing a field with the number of records.
On Thu, Feb 15, 2007 at 01:04:26AM +, Nuno Oliveira wrote:
> Hi,
>
> I've used PHP with MySQL and I was able to count the rows of a table by
> using the following code:
>
> SELECT SQL_CALC_FOUND_ROWS * FROM MyTableName;
> SELECT FOUND_ROWS();
>
> However, I
Nils Meyer wrote:
> SELECT
SQL_CALC_FOUND_ROWS doesn't make much sense without a where clause by
the way.
LIMIT, not where.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
ECT FOUND_ROWS() returns exactly
one record *CONTAINING* the number of found rows. So you have to access
the resultset to get the actual number of rows. SELECT
SQL_CALC_FOUND_ROWS doesn't make much sense without a where clause by
the way.
regards
Nils
--
MySQL General Mailing List
Hi,
I've used PHP with MySQL and I was able to count the rows of a table by
using the following code:
SELECT SQL_CALC_FOUND_ROWS * FROM MyTableName;
SELECT FOUND_ROWS();
However, I would like to do the same thing using Visual Basic 6...
When I set the RS.Source to the first SELECT stat
Hello.
> data, if may grow, I like the cleanness of the SQL_CALC_FOUND_ROWS,
> however, currently, it is only saving me code, not performance.
Often it is ok to have more complex code to get better performance.
You should decide what is important for you - clearness of the code, or
4.0.18-standard-log
Having some performance issues, and I can not see why:
SELECT SQL_CALC_FOUND_ROWS l.id, u.b_first_name FROM logbook AS l LEFT JOIN
users AS u ON l.user_id = u.id ORDER BY id DESC LIMIT 0, 20;
20 rows in set (1.21 sec)
If I take out the SQL_CALC_FOUND_ROWS, of course, it is
Matt Babineau wrote:
> Ok I installed PHP 4.3.10 and it still has not fixed the problem. If I
> remove the SQL_CALC_FOUND_ROWS from the query, it works no problems! This
> is
> very strange behavior!
Not really that strange, I think...
While you might want to read this:
http:/
9:20 PM
Subject: Problem with SELECT SQL_CALC_FOUND_ROWS
> Hi All-
>
> I'm running a query that uses SQL_CALC_FOUND_ROWS for my search engine on
a
> real estate site. The problem is that I get an error when I run my query:
>
> "Warning mysql_query(): Unable to sav
: Michael Stassen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 01, 2005 3:55 PM
To: Michael Dykman
Cc: Matt Babineau; 'MySQL General'
Subject: Re: Problem with SELECT SQL_CALC_FOUND_ROWS
I'm confused. That bug was closed over 2 years ago. What makes you think
it applies here, and
e
what happens?
Matt Babineau
Criticalcode
w: http://www.criticalcode.com
p: 858.733.0160
e: [EMAIL PROTECTED]
-Original Message-
From: Michael Dykman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 01, 2005 12:47 PM
To: Matt Babineau
Cc: 'MySQL General'
Subject: Re: Problem with SE
al Message-
> From: Michael Dykman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 01, 2005 12:47 PM
> To: Matt Babineau
> Cc: 'MySQL General'
> Subject: Re: Problem with SELECT SQL_CALC_FOUND_ROWS
>
> Matt,
>
> I suspect your problem is PHP, not My
Ok I installed PHP 4.3.10 and it still has not fixed the problem. If I
remove the SQL_CALC_FOUND_ROWS from the query, it works no problems! This is
very strange behavior!
Matt Babineau
Criticalcode
w: http://www.criticalcode.com
p: 858.733.0160
e: [EMAIL PROTECTED]
-Original Message
:47 PM
To: Matt Babineau
Cc: 'MySQL General'
Subject: Re: Problem with SELECT SQL_CALC_FOUND_ROWS
Matt,
I suspect your problem is PHP, not MySQL. refer to
http://bugs.php.net/bug.php?id=16906&edit=1
On Tue, 2005-02-01 at 15:20, Matt Babineau wrote:
> Hi All-
>
&
Matt,
I suspect your problem is PHP, not MySQL. refer to
http://bugs.php.net/bug.php?id=16906&edit=1
On Tue, 2005-02-01 at 15:20, Matt Babineau wrote:
> Hi All-
>
> I'm running a query that uses SQL_CALC_FOUND_ROWS for my search engine on a
> real estate site.
Ok here is the code chunk:
$rows = is_numeric($_GET['rows']) ? $_GET['rows'] : 5;
$stRow = 0;
// SEARCH CODE
$sql = "SELECT SQL_CALC_FOUND_ROWS propertyData.*,
propertyDataBulk.propertyDesc FROM propertyData LEFT JOIN propertyDa
"Matt Babineau" <[EMAIL PROTECTED]> wrote on 02/01/2005 03:20:49 PM:
> Hi All-
>
> I'm running a query that uses SQL_CALC_FOUND_ROWS for my search engine
on a
> real estate site. The problem is that I get an error when I run my
query:
>
> "Warning
Hi All-
I'm running a query that uses SQL_CALC_FOUND_ROWS for my search engine on a
real estate site. The problem is that I get an error when I run my query:
"Warning mysql_query(): Unable to save result set in /clients/search.php"
My Query is:
SELECT SQL_CALC_FOUND_RO
Hello!
I am facing a problem when using SQL_CALC_FOUND_ROWS in certain queries.
The query where I am ordering by a column is much more slowly than the same
query NOT using SQL_CALC_FOUND_ROWS
select SQL_CALC_FOUND_ROWS * from table by date desc
- this query takes about 1.2 s
select * from
Hello!
I am facing a problem when using SQL_CALC_FOUND_ROWS in certain queries.
The query where I am ordering by a column is much more slowly than the same
query NOT using SQL_CALC_FOUND_ROWS
select SQL_CALC_FOUND_ROWS * from table by date desc
- this query takes about 1.2 s
select * from
Hello,
> > Could one not store the total while using the
> index
> > and use "select FOUND_ROWS()" without
> > SQL_CALC_FOUND_ROWS to retrieve the total?
>
> Yes, it could.
> It is the optimization that wasn't implemented yet.
> (but it's in t
Hi!
On Dec 05, tk wrote:
> Hello Sergei, Gunnar, and others,
>
> thank you for your quick responses.
> One little mystery remains:
>
> Why does one need to read all the row data (with
> SQL_CALC_FOUND_ROWS) to get the total number of
> results when using a limit?
>
Hello Sergei, Gunnar, and others,
thank you for your quick responses.
One little mystery remains:
Why does one need to read all the row data (with
SQL_CALC_FOUND_ROWS) to get the total number of
results when using a limit?
When the index is used to find relevant rows and sort
the results, the
Hi TK,
There was an optimizer bug in MySQL 4.0
This bug is fixed in 4.0.17 (not yet released)
# Fixed bug when the optimiser did not
# take SQL_CALC_FOUND_ROWS into account
# if LIMIT clause was present. (Bug #1274)
Kind regards
Gunnar
> -Original Message-
> From: [EMAIL PRO
Hi!
On Dec 04, tk wrote:
> Hello,
>
> Thanks for the response.
> There is one thing that is not clear however.
>
> Regardless of whether or not I perform the fulltext
> search with or without the SQL_CALC_FOUND_ROWS
> keyword, the results that I get are exactly t
Hello,
Thanks for the response.
There is one thing that is not clear however.
Regardless of whether or not I perform the fulltext
search with or without the SQL_CALC_FOUND_ROWS
keyword, the results that I get are exactly the same.
Also, the notion of stopping after the limit is
reached
Hi,
Yes, you would have similar results with any query that uses
SQL_CALC_FOUND_ROWS. That's because MySQL has to see how many rows would
be found without the LIMIT. So in your case, it can't just abort the
query after it finds 10 rows. All rows that match the WHERE need to be
found.
('some_search_term')
LIMIT 0,10
However, when i add the SQL_CALC_FOUND_ROWS keyword
like in the following query, some queries take longer
than 1 minute:
SELECT SQL_CALC_FOUND_ROWS something
FROM some_table
WHERE MATCH (some_column) AGAINST ('some_search_term')
LIMIT 0,10
How can there be
[EMAIL PROTECTED] writes:
> >Description:
> *** against BK as of set 1.1144 ***
>
> It appears that putting SQL_BUFFER_RESULT and SQL_CALC_FOUND_ROWS
> in the same SELECT statement is a really bad idea!
>
> SELECT FOUND_ROWS() after
>Description:
*** against BK as of set 1.1144 ***
It appears that putting SQL_BUFFER_RESULT and SQL_CALC_FOUND_ROWS
in the same SELECT statement is a really bad idea!
SELECT FOUND_ROWS() after SELECT SQL_BUFFER_RESULT SQL_CALC_FOUND_ROWS
either return
31 matches
Mail list logo
