D
Darren Fuller
my two cents..
I stared out using ms vb and ms access and borland delphi. Been using
them since they were all created. So, I've seen quite a few changes. And
this has sometimes been painful.
I agree that you can't compare the objects in ADO.NET with previous
technologies. .Net changed a lot from DAO, ADO, and OLEDB. You can do
everything you used to - just a little differently, and sometimes a
little more work. I also wouldn't compare Borand and MS when it comes to
data access. I love Delphi and C++ builder but I haven't always been
thrilled with their options for data access, much less their
performance. But it was easy and powerful if used correctly.
All that being said..
I was quite upset when I discovered that the "OLD" functionality I was
used to was not incorporated within .NET, specifically the different
types of cursors and how they could be used. In my opinion it was not
necessary to completely remove these "options" from developers because
developers abused how they should be used. Microsoft could have created
a Recordset object as it was in the older versions within .NET and it
still would have value. To say that any object (DataSet, DataReader,
DataTable, etc) in .NET are the same as a Recordset isn't correct,
either. You can use the .NET objects to accomplish any of the old tasks
but they are not the same in their ease of use - you have to do a lot
more work to do some things.
Also, not every application has to scale. I've worked in environments
where I constantly put together small applications in VB or MS ACCESS
and I still used the old components (DAO, ADO) for these applications.
Why would I want a disconnected object from within MS ACCESS that's
going to reside on a client's pc and never go anywhere? For larger -
need to scale applications - ADO.NET is the best choice by far.
Wishing Microsoft would have giving me a Recordset I was famaliar with
does not make me a poor programmer. I don't like it when someone removes
a functionality either - And I know and use ADO.NET, VS.NET as well as
I've used other environments. I adapted. To me, having this
functionality in .NET would not have been a bad thing. But obviously, if
abused like before it could have casted a bad review for .NET. So, I
understand why it was not incorporated. But I don't have to like it. And
I can relate the original posters frustration with it. My only advice is
what most of the responders have offered. Learn ADO.NET as well as you
knew the other environments and make the best of it.
So, I wouldn't say that ADO.NET data access sucks. In all I think it
really is more versatile than pervious technologies. But that old
Recordset objects really rocks, even today when I need it. Too bad Def
Leopard can't say the same.
I stared out using ms vb and ms access and borland delphi. Been using
them since they were all created. So, I've seen quite a few changes. And
this has sometimes been painful.
I agree that you can't compare the objects in ADO.NET with previous
technologies. .Net changed a lot from DAO, ADO, and OLEDB. You can do
everything you used to - just a little differently, and sometimes a
little more work. I also wouldn't compare Borand and MS when it comes to
data access. I love Delphi and C++ builder but I haven't always been
thrilled with their options for data access, much less their
performance. But it was easy and powerful if used correctly.
All that being said..
I was quite upset when I discovered that the "OLD" functionality I was
used to was not incorporated within .NET, specifically the different
types of cursors and how they could be used. In my opinion it was not
necessary to completely remove these "options" from developers because
developers abused how they should be used. Microsoft could have created
a Recordset object as it was in the older versions within .NET and it
still would have value. To say that any object (DataSet, DataReader,
DataTable, etc) in .NET are the same as a Recordset isn't correct,
either. You can use the .NET objects to accomplish any of the old tasks
but they are not the same in their ease of use - you have to do a lot
more work to do some things.
Also, not every application has to scale. I've worked in environments
where I constantly put together small applications in VB or MS ACCESS
and I still used the old components (DAO, ADO) for these applications.
Why would I want a disconnected object from within MS ACCESS that's
going to reside on a client's pc and never go anywhere? For larger -
need to scale applications - ADO.NET is the best choice by far.
Wishing Microsoft would have giving me a Recordset I was famaliar with
does not make me a poor programmer. I don't like it when someone removes
a functionality either - And I know and use ADO.NET, VS.NET as well as
I've used other environments. I adapted. To me, having this
functionality in .NET would not have been a bad thing. But obviously, if
abused like before it could have casted a bad review for .NET. So, I
understand why it was not incorporated. But I don't have to like it. And
I can relate the original posters frustration with it. My only advice is
what most of the responders have offered. Learn ADO.NET as well as you
knew the other environments and make the best of it.
So, I wouldn't say that ADO.NET data access sucks. In all I think it
really is more versatile than pervious technologies. But that old
Recordset objects really rocks, even today when I need it. Too bad Def
Leopard can't say the same.