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 <vernondc...@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 <cenov...@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@lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
