ADO.NET 2.0 - ResultSet concerns

  • Thread starter Thread starter William Ryan eMVP
  • Start date Start date
W

William Ryan eMVP

I considered posting this OT, but I think it's relevant nonetheless. I've
been trying to get familiarized with ADO.NET 2.0 for a while now, and I have
the newest version of VS 2005 which I'm referring to. As much as I like
what MS is doing, I'm concerned it's going to be VERY Problematic. (I know,
that alone shouldn't impede progress and making omelettes requires a few
broken eggs and all that stuff but I'm wondering what the deal is).

Read through this NG and you'll see many many of the same recurring
problems. Nothing different hear from other NG's. However, I think ADO.NET
was such a conceptual shift from ADO that a lot of people (A LOT) are
seriously lacking in their understanding of the how's/why's and
implementation of it. I'm not in any way besmirching any such
individuals..my learning curve was far from perfect and I certainly made a
lot of the mistakes I'm referring to...but ADO.NET is the most radical shift
in paradigms in the whole .NET framework vs. Old School.

In comes the ResultSet. I like it quite a bit and I think it's a move
forward. With that said, I also think it's a disaster waiting to happen.
Why?

- ADO.NET is billed as a 'disconnected' methodology. In fact, it is for
the most part. Unless you use a DataReader or Command.Executexxx methods.
No biggy there, but a LOT of people still have trouble distinguishing when
where to use the two. How many data access layers have we all seen where
people are trying to pass a DataReader through layers or threads thinking
it's not 'safe' to do? Threading is a little more obvious, but if the DAAB
passes datasets through layers via ExecuteDataset, it's not surprising that
many newbies think the same should work with DataReaders.

So, we have Disconnected ADO.NET and Connected ADO.NET with a pretty clear
distinction (except for databinding in ASP.NET Datagrid which allows
executeReader but that's another issue).

So the golden rule is Open your connection Only when you need to and close
it ASAP. Very easy concept by and large, but not necesssarily intuitive.
There are tons of posts where people want to 'leave a connection open'
through an entire user session for performance reasons. There are also tons
of posts where people want to use only one connection.

Where does the resultset fit into this? I can go on and on about the
distinction between it and a datareader, I can go on and on about server
side cursors and the underlying architecture which will allow you to go
wherever you want in your results.

But how do I explain in a concise and "correct" way when the newbies start
asking.... "When should I use a xxxDataReader and a xxxResultSet?"
And tell me that Disconnected methodology isn't going to be widely abandoned
by 1) newbies 2) former ADO users 3) people who still don't like dealing
with disconnected nuances?

If it's updateable....everyone is going to use it as a magic bullet.."Gee
it's faster, easier to use and the only tradeoff is keeping a connection
open, heck I wanted to do that anyway". A datareader would have to be an
order of magnitude faster to make it more desirable for many folks. Then
throw in that it has a similar syntax to ado (NextResult, ReadFirst,
ReadLast etc) with similar functionality and basically I see one big ADO
Reborn.

So in a nutshell, I think it's cool and has many virtues. I also think that
after a 3 year push to getting people to embrace "Disconnected" Methodology,
it's going to be a step backward. Some have went so far as calling it MS's
retreat on the disconnected model...I wouldn't go that far, but it's a more
than fair assertion.

Any ideas?


Cordially,

W.G. Ryan MVP
Windows - Embedded
http://www.msmvps.com/WilliamRyan/
dotnetguru at co

mcast dot net
wgryan at mvps dot org
bill at devbuzz dot com
www.devbuzz.com
www.knowdotnet.com
 
William:

I wouldn't categorize the feature as a "retreat" on the disconnected
model either, and I'm always happy to see new features and
capabilities added to the framework.

That being said...

It has felt like an uphill batlle here to get people over the
connected mindset and the hill looks like it gets steeper. Hopefully
the code wizards in 2005 will be a big help and get people started in
the right direction with effective code. We may not be able to get
features removed (and really I would not want to) but I think a strong
community voice could take care of shoddy code generation.

Yukon also makes me edgy. Having the CLR around will be a blessing in
many scenarios but I'm sure there will be some solutions out there
cursed with lots of procedural gook in the DB and much the worse for
it.
 
Hi Bill,

History always repeats.
When I started data processing, it was in the time of the punching cards.
People where sorting them column by column, when you have to do a lot of
columns and a hugs amount of cards that is hard labour.

There where also machines with which what you could do intelligent sequence
checking by making let say program boards (was with wires), took sometimes
time how to do it, but when you did know how, it was very easy to do (It
was collecting the good sequences into the others while creating let say
streams again from the wrongs ones).

I think you have seen messages enough from me to understand which way I
took. However, there where people in my environment who said I was only
lazy.

Then we got magnetic tape, that method that I did was of course also one of
the better methods to sort a tape. However, I did not like the magnetic
tape; I did like the disc and especially the disc that could read fast
randomly.

However, there where people who said using a random disc was not sure and
not as fast as a magnetic tape and they did use the magnetic disc as a tape.
(Do understand me; there are problems, which still can be done the best way
doing that.)

I can go on of course, but what I want to say is that there are companies
which have there biggest earnings from those people I tell you about. They
still have environments build on the principles of the punch card or
environments build on the time the students came in the computing business.

One of the things I have always like from Microsoft is that they did not
listen to those people who are stopping progression. I hope this will be the
same in future.

Just my thoughts about your message,

Cor
 
Hi Cor:

I appreciate your opinion and just wanted to follow up. I think we both
agree that progress is good and that you need to go forward. If the
resultset was included from the beginning, I think it would be a LOT less
confusing for newbies. Maybe I'm just being a bit pessimistic in this
regard, but i foresee a ton of confusion b/c there's still a ton of
confusion and this will only blur the line. I suspect that many ADO
programmers are going to rely on it exclusively and I just foresee some
confusion. However, when I start sounding like a Chicken-Little, that's a
good indicator that I need to quit philosophizing and start reading more
about a subject.

Thanks again,

Bill

BTW, I responded to the DataReader Limitation post. didn't mean to step on
any toes there ;-)
 
Hi Bill,

I think we both should reread what I did write, I do totaly agree with you
and was very happy you wrote it and I could connect to it.

I hope that was what you did read also, because now I become in doubt.

(I do not know Net 2005, however again back to the connected method is for
me back to the past, although ADSL can do a lot for Internet, for the
disconnectiong computing I think it means nothing, or is it relying on
faster wireless telephone solutions).

Cor
 
William,
I believe that you have been able to capture the soul of the argument in
these posts, the short and the long of it is that there are some very
specific problems that absolutely require a connected resultset (Some OLTP
apps for example), this feature is also the cornerstone of a much more
requested feature, Paging. However, using this feature when it is not
required is disastrous for scalability and it is almost guaranteed that it
will be miss-used, in fact, I cannot think of a good use of Paging at all.
IMO used in asp.net pages it will slow down servers to a crawl. Another good
point is that, like you mentioned, adding this feature now is going to
confuse the message that we have only now started to get through. The last
point is that for the very rare app that requires server side cursors you
can always use ado or create the cursor yourself with TSQL "declare c CURSOR
DYNAMIC for SELECT ..."

Practically everybody that I have talked to about the v2.0 ado.net features
places this at the top of his concern list and we are looking very carefully
at these features. Thanks for bringing this up, I will forward your comments
appropriately.
 
Hi Angel,

I'd so like the SqlResultset object to not make it into the next release. It
will be the most misused feature ever. Most of the problems people had with
ADO was misuse of server-side cursors.

Regards,

--
Greg Low (MVP)
MSDE Manager SQL Tools
www.whitebearconsulting.com

Angel Saenz-Badillos said:
William,
I believe that you have been able to capture the soul of the argument in
these posts, the short and the long of it is that there are some very
specific problems that absolutely require a connected resultset (Some OLTP
apps for example), this feature is also the cornerstone of a much more
requested feature, Paging. However, using this feature when it is not
required is disastrous for scalability and it is almost guaranteed that it
will be miss-used, in fact, I cannot think of a good use of Paging at all.
IMO used in asp.net pages it will slow down servers to a crawl. Another good
point is that, like you mentioned, adding this feature now is going to
confuse the message that we have only now started to get through. The last
point is that for the very rare app that requires server side cursors you
can always use ado or create the cursor yourself with TSQL "declare c CURSOR
DYNAMIC for SELECT ..."

Practically everybody that I have talked to about the v2.0 ado.net features
places this at the top of his concern list and we are looking very carefully
at these features. Thanks for bringing this up, I will forward your comments
appropriately.
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.


William Ryan eMVP said:
Hi Cor:

I appreciate your opinion and just wanted to follow up. I think we both
agree that progress is good and that you need to go forward. If the
resultset was included from the beginning, I think it would be a LOT less
confusing for newbies. Maybe I'm just being a bit pessimistic in this
regard, but i foresee a ton of confusion b/c there's still a ton of
confusion and this will only blur the line. I suspect that many ADO
programmers are going to rely on it exclusively and I just foresee some
confusion. However, when I start sounding like a Chicken-Little, that's a
good indicator that I need to quit philosophizing and start reading more
about a subject.

Thanks again,

Bill

BTW, I responded to the DataReader Limitation post. didn't mean to step on
any toes there ;-)
one
of best
way be
the
Click to expand...
Click to expand...
 
We received this same feedback across the board. Based on that feedback we
re-evaluated SqlResultSet, and the current thinking is that we'll not ship
it with Whidbey.

I'd like to thank all of you for the feedback. Please keep it coming for
other new ADO.NET features as well! We really appreciate your feedback and
we do our best to incorporate it into the product.

--
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corp.

This posting is provided "AS IS" with no warranties, and confers no rights.


Greg Low (MVP) said:
Hi Angel,

I'd so like the SqlResultset object to not make it into the next release. It
will be the most misused feature ever. Most of the problems people had with
ADO was misuse of server-side cursors.

Regards,

--
Greg Low (MVP)
MSDE Manager SQL Tools
www.whitebearconsulting.com

Angel Saenz-Badillos said:
William,
I believe that you have been able to capture the soul of the argument in
these posts, the short and the long of it is that there are some very
specific problems that absolutely require a connected resultset (Some OLTP
apps for example), this feature is also the cornerstone of a much more
requested feature, Paging. However, using this feature when it is not
required is disastrous for scalability and it is almost guaranteed that it
will be miss-used, in fact, I cannot think of a good use of Paging at all.
IMO used in asp.net pages it will slow down servers to a crawl. Another good
point is that, like you mentioned, adding this feature now is going to
confuse the message that we have only now started to get through. The last
point is that for the very rare app that requires server side cursors you
can always use ado or create the cursor yourself with TSQL "declare c CURSOR
DYNAMIC for SELECT ..."

Practically everybody that I have talked to about the v2.0 ado.net features
places this at the top of his concern list and we are looking very carefully
at these features. Thanks for bringing this up, I will forward your comments
appropriately.
--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.


William Ryan eMVP said:
Hi Cor:

I appreciate your opinion and just wanted to follow up. I think we both
agree that progress is good and that you need to go forward. If the
resultset was included from the beginning, I think it would be a LOT less
confusing for newbies. Maybe I'm just being a bit pessimistic in this
regard, but i foresee a ton of confusion b/c there's still a ton of
confusion and this will only blur the line. I suspect that many ADO
programmers are going to rely on it exclusively and I just foresee some
confusion. However, when I start sounding like a Chicken-Little,
Click to expand...
Click to expand...
that's
a step
on
Click to expand...
lot
of do
(It
Click to expand...
way
I sure
and about.
They
Click to expand...
will
be
Click to expand...
Click to expand...
 
Back
Top