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

[Hank Fay]

Hi Vernon,

have you looked at Microsoft.Data.Database, which comes with LightSwitch?  I
think it might have what you need in terms of methods and properties.  It
does require .Net 4.0.

Hank

On Tue, Aug 10, 2010 at 12:41 PM, Vernon Cole <vernondcole at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/8f6cefe8/attachment.html>