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

[Lukas Cenovsky]

  He is probably talking about this:
http://weblogs.asp.net/davidfowler/archive/2010/08/02/introduction-to-microsoft-data-dll.aspx

 From reading the article, I don't think it is the way to go.

--
-- Lukas


On 11.8.2010 19:19, Vernon Cole wrote:
> Hank:
>  Never heard of it (before). A quick search of google and msdn only 
> tells me that LightSwitch is soon to be released in beta.  As a full 
> time college student (how did I get myself into this at the age of 
> 60?) I can get access to lots of free, new, and beta stuff.  Do you 
> have links?
> (send privately if need be.)
> --
> Vernon
>
> On Tue, Aug 10, 2010 at 12:49 PM, Hank Fay <hank at prosysplus.com 
> <mailto:hank at prosysplus.com>> wrote:
>
>     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 <mailto: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 <http://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 <http://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 <http://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 <mailto: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
>             <http://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
>             <http://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 <mailto:Users at lists.ironpython.com>
>             http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>         _______________________________________________
>         Users mailing list
>         Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
>         http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.ironpython.com <mailto: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/20100811/e0b3c0dc/attachment.html>