Hi Thomas,
I can confirm that using SQL_CONCUR_READ_ONLY instead of
SQL_CONCUR_LOCK fixes the problem.
Regards,
Ajit
-----Original Message-----
From: Koetter, Thomas Theodor [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 2:07 PM
To: 'Ajit Aranha'
Subject: RE: ODBC and select count queries
Hi Ajit,
thx for the example. The problem is probably the line
ret = SQLSetStmtOption(m_stmt, SQL_CONCURRENCY,SQL_CONCUR_LOCK);
Here
ret = SQLSetStmtOption(m_stmt, SQL_CONCURRENCY,SQL_CONCUR_READ_ONLY);
should work.
Explanation:
If the concurrency is not SQL_CONCUR_READ_ONLY, the select command is
send
with the suffix "FOR REUSE" to the kernel. This means, the result set
will be build inside the kernel.
A "select count(*)" returns only a single value so building a result set
wouldn't gain anything but would need resources inside the kernel.
So the kernel rejects the statement.
Otherwise the ODBC driver does not analyze the SQL statements except the
first key word. So the driver knows, a select is running, but it does
not
know, that it is a "select count()".
If the problem is solved at your site, please send an answer to the
list.
HTH Thomas
----------------------------------------------
Dr. Thomas K�tter
SAP AG, SAP Labs Berlin
Do you know SAP^H^H^H MaxDB ? www.sapdb.org
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
