I was approaching the conclusion that this is expected behavior. Glad to have it confirmed with a reasonable explanation why. I guess the fix will be to document the behavior.
Thanks, Michael Manfre On Fri, Jun 22, 2012 at 11:38 PM, Chris Lambacher <ch...@kateandchris.net>wrote: > > > On Wed, Jun 20, 2012 at 10:50 AM, Michael Manfre <mman...@gmail.com>wrote: > >> The observed behavior is equivalent to this bit of SQL. >> >> DECLARE @retval int, @someOut int >>> exec @retval = uspReturnsAResultSetOrTwo @someOut OUTPUT >>> SELECT @retval, @someOut >>> >> >> I haven't been able to find any documentation stating that this is the >> intended behavior and this doesn't match my experience of using stored >> procedures with ADO.NET. Is this expected behavior? Is there some >> combination of cursor types or attributes to get the output parameter >> values without fetching/skipping all the recordsets? >> > > This is the behaviour of the Microsoft's ADO library which is the > underlying api that adodbapi works against. It is pretty hard to find docs > for ADO because ADO.NET sucks up all the hits and Microsoft's own MSDN > docs for ADO are pretty weak. Also, that is fundamentally the pattern you > would use with ODBC too which does not have any particular notion of Stored > Proceedures. ADO is based on ODBC connections so that may be the source of > this particular behind the scenes idiom. > > -Chris > > -- > Christopher Lambacher > ch...@kateandchris.net >
_______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32