Edit report at https://bugs.php.net/bug.php?id=72503&edit=1
ID: 72503
User updated by: jgeert1 at its dot jnj dot com
Reported by: jgeert1 at its dot jnj dot com
Summary: [ODBC Cursor Library] Result set was not generated
by a SELECT statement, SQL s
Status: Not a bug
Type: Bug
Package: ODBC related
Operating System: Windows Server 2008 R2
PHP Version: 5.6.23
Block user comment: N
Private report: N
New Comment:
I still don't get it completely. When I use the method as described below, I can retrieve all
records that I've selected as long as it doesn't contain any column that's defined as
varchar(max) or nvarchar(max). If your statement is true, I also should also have problems when
retrieving the other type of data. Which is not the case at all, these are retrieved fine.
I probably could use some guidance here. I've did a lot of performance tests using all types of
cursors, but I'm getting stuck with most of them.
If I'm using the default cursor (static), and use SQL_CUR_USE_DRIVER, the retrieval of the data
is slow (when I use SQL_CURSOR_FORWARD_ONLY or SQL_CURSOR_KEYSET_DRIVEN, the performance is more
than 100 times better).
So I also did a test with SQL_CUR_USE_ODBC and a static cursor. Performance was ok (also fast), but
I noticed that I did not receive all rows, the data was cut off somewhere and no errors were shown.
If I increase the value of "defaultlrl" to a value of 8192, I even get less rows, reducing
the value resulted in more rows returned. The problem was that I needed all the rows, so this was
not an option for me.
The best results were achieved by using SQL_CUR_USE DRIVER and using SQL_CURSOR_FORWARD_ONLY and
SQL_CURSOR_KEYSET_DRIVER. Both provided me with all rows (changing defaultlrl had no impact - all
rows were returned), except that I'm getting errors when I try to retrieve rows that have
varchar(max) or nvarchar(max) type of columns.
So now I'm stuck ....
Previous Comments:
------------------------------------------------------------------------
[2016-07-06 12:34:28] ab@php.net
Yep, you're right, that's default. However it doesn't change anything on the API
restrictions (see my previous link). Data can be fetched different ways, the most convenient for PHP
is by utilizing SQLGetData(). More about data fetching https://msdn.microsoft.com/en-us/library/ms131269.aspx
.
This does condition the static cursor as default in PHP. I currently don't see a way to move
away from SQLGetdata() without a significant rewrite of ext/odbc. But also i'd doubt the real
gain it could might bring. Clear, column or even row size binding might be faster, but there is a
variety of use cases that could easily negate this advantage. And given it's currently an API
restriction, classified as a non bug for PHP.
Thanks.
------------------------------------------------------------------------
[2016-07-06 10:30:37] jgeert1 at its dot jnj dot com
I do not agree on that one:
Please read: https://technet.microsoft.com/en-us/library/ms130807(v=sql.110).aspx
SQL_CURSOR_FORWARD_ONLY is the default setting for the SQL Server Native Client ODBC driver.
------------------------------------------------------------------------
[2016-07-06 10:00:31] ab@php.net
Typo - "if the row set size > 1".
Thanks.
------------------------------------------------------------------------
[2016-07-06 09:55:09] ab@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system
is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Thanks for the additional info. In this case, it is an inappropriate configuration. Forward-only
cursors shouldn't be used, if the rowset size >= 1. It is documented here https://msdn.microsoft.com/en-us/library/ms715441(v=vs.85).aspx
Thanks.
------------------------------------------------------------------------
[2016-07-04 13:47:46] jgeert1 at its dot jnj dot com
Meanwhile after doing some additional testing, I noticed that I only have this error when a table
has columns defined as "ntext" or "varchar(max)" or "nvarchar(max)"
fields. If I remove these columns from my sql statement, the query runs fine again.
When I create a dummy table like this:
CREATE TABLE [dbo].[jg_test](
[id] [int] IDENTITY(1,1) NOT NULL,
[test1] [int] NULL,
[test2] [varchar](50) NULL,
[test3] [varchar](max) NULL,
[test4] [nvarchar](max) NULL,
[test5] [int] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
just add some dummy data to it (in my case the varchar fields only contain "test").
use this code to access it:
$user = "username";
$pwd = "password";
$dsn = "Driver={SQL Server Native Client
11.0};Server=myserver;Database=mydb;MARS_Connection=Yes;";
ini_set ('odbc.default_cursortype',SQL_CURSOR_FORWARD_ONLY);
$dbhandle = odbc_connect($dsn,$user,$pwd,SQL_CUR_USE_DRIVER);
$result = odbc_exec($dbhandle, "select * from dbo.jg_test");
while( $row = odbc_fetch_array($result)) {
var_dump($row);
}
odbc_free_result($dbhandle);
odbc_close($dbhandle);
This will result in the error message:
Warning: odbc_fetch_array(): SQL error: [Microsoft][SQL Server Native Client 11.0]Invalid Descriptor
Index, SQL state S1002 in SQLGetData
I know it's a different error message then the one posted before, but I'm sure that these
are related to each other.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=72503
--
Edit this bug report at https://bugs.php.net/bug.php?id=72503&edit=1