[freetds] Invalid cursor state when executing 2 SELECTstatements
ZIGLIO, Frediano, VF-IT
Frediano.Ziglio at vodafone.com
Fri Dec 21 10:39:08 EST 2007
> 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
> 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):
> 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...
More information about the FreeTDS