[IronPython] Fwd: [DB-SIG] How can I reliably detect whether an SQL statement is a Query?

[Vernon Cole]

I am afraid Lukas is very correct.  (Thanks, you really saved me a lot of
debugging time.)

This will be an anti-announcement.  I got a version (2.4.1A1) of adodbapi
working (sort of) on ADO.NET and splatted up against enough difficulties
that I have shelved the effort for the present time.  I have committed my
efforts to a new branch (named ado.net) on the mercurial source tree at
http://sourceforge.net/projects/adodbapi/develop for anyone who would like
to take up the effort.  It might be worthwhile to continue development on an
SQL-server specific version, especially if someone has MONO in mind.  Since
I intended adodbapi to be as universal as possible, I did not want to go
that direction.

The problems I found were:
1) Lukas was right -- only one datareader per connection. Messes up cursor
usage as per the api.
2) cursor.rowcount becomes useless for SELECTs.
3) Connection timeouts are only supported by adding text to the connection
strings -- which breaks JET.
4) The "internal size" for cursor.description[3] cannot be retrieved.
5) fine control of cursor location and isolation level is lost.
6) MS documentation vaguely suggests that using ExecuteReader for a command
which returns no dataset is a bad idea, which may mean that there is a
problem with a stored procedure which may not return a dataset.
7) MS documentation hints that schema results (which are processed into
cursor.description) may be incorrect unless a "keyinfo" flag is passed to
ExecuteReader, the use of which will cause several possible side effects to
the data retrieval.
8) Use of a datareader implies no recordset, so I have to emulate a
recordset within my SQLrows object.
9) ADO.NET still uses a COM interface internally to communicate with ADO
data adapters -- so what's the point of not using COM directly in my code
and keeping all of the lost features?

So the COM implementation of adodbapi v2.4.0 will remain as the official
"latest and greatest" for IronPython.

Thanks for all the fish...
Vernon Cole

On Tue, Aug 3, 2010 at 2:17 PM, Lukas Cenovsky <cenovsky at bakalari.cz> wrote:

>  On 3.8.2010 1:24, Vernon Cole wrote:
>
> What are the consequences of using ExecuteReader() when there is
>  nothing to read? If none, i.e. you get an empty set of results, then I
>  would say to use that all the time, and don't bother to examine your
>  SQL at all.
>
>
> I think ExecuteReader should work for everything. I use only ExecuteReader
> in my private tool (but I do not use stored procedures).
>
> You will have a bigger problem with ADO.NET than this. According to the
> Python dbapi specification, you can have as many cursors per connection as
> you want. You can have many cursors in ADO.NET too, but you can have only
> one SqlDataReader per connections which makes several cursors per connection
> useless.
>
> --
> -- Lukas
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20100810/1d08e557/attachment.html>