FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> Hi Frediano,
> 
> First, thanks a lot for looking at this cursor issue!
> 

I just committed a patch to CVS... all tests you sent me are
incorporated and working as expected!

> ZIGLIO, Frediano, VF-IT wrote:
>  > I think I have to check how attributes change in MS ODBC... perhaps
>  > setting SENSITIVITY change also CURSOR_TYPE ??
> 
> As I wrote in a previous mail, you should test all possible 
> combinations
> of SQL Statement handle attributes with the MS ODBC MDAC 
> dribver, and see
> in the SQL Server Profiler trace what sp_cursor* calls it generates.
> 
> Resource in SQL Server 2005 MSDN (you probably know about this link):
> 
> http://msdn2.microsoft.com/en-us/library/ms130794.aspx
> 
> ...
> 
> We do use the following SQLSetStmtAttr() attributes:
> 
> For scrollable cursors:
> 
>      SQL_ATTR_CURSOR_SCROLLABLE, SQL_SCROLLABLE
>      SQL_ATTR_CURSOR_SENSITIVITY, SQL_INSENSITIVE
> 
> For SELECT FOR UPDATE cursors (forward only):
> 
>      SQL_ATTR_CONCURRENCY, SQL_CONCUR_LOCK
> 

Fixed sensitivity setting some days ago.

A note about implementation. Currently we don't use sp_cursorprepare,
sp_cursorprepexec , sp_cursorexecute and sp_cursorunprepare that is we
don't use prepared cursors but we use sp_cursoropen with parameters. You
should note some penalty only cause execute plans are not reused so
often... well... I'm not exactly sure this is a big penalty cause sql
should cache plans even on normal queries... also I don't think cursors
with parameters are reused so often... considering that you don't have
to call sp_cursorunprepare if statement close you could even get some
network improves... who knows...

freddy77