ODBC Traces can be found here: 
https://gist.github.com/anonymous/f91784cedbe6a6eb58e88b814deef5c6

Please provide the full reproduce way with table creaton, data, and all the necessary things.

Thanks.

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.

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.

Typo - "if the row set size > 1".

Thanks.

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.

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.

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 ....