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