[IronPython] Fwd: [DB-SIG] How can I reliably detect whether an SQL statement is a Query?
hank at prosysplus.com
Tue Aug 10 11:49:21 PDT 2010
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.
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 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
>> -- Lukas
>> Users mailing list
>> Users at lists.ironpython.com
> Users mailing list
> Users at lists.ironpython.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users