Re: Database access sucks!

From: Gerry Hickman (gerry666uk_at_yahoo.co.uk)
Date: 03/09/05 

Date: Wed, 09 Mar 2005 22:26:12 +0000

Hi Darren,

You are right that a lot of things went downhill with the introduction
of .NET. I currently use JScript with ADO. I can write it in half the
time, with nothing more than a text editor and it runs on any windows
machine regardless of what "framework" is installed, with a few KB of
overhead instead of 65Mb, and fantastic speed. It works with everything
from XML, CSV, Acess JET, SQL Server etc.

I don't agree with you about DAO though, you should NOT use DAO - it sucks.

The main focus of .NET is so that beginners can drag "controls" onto
"forms" without understanding what's going on behind the scenes. If you
need to do some serious programming, leave the .NET at home:)

Darren Fuller wrote:

> 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.
>
> :-)
>
> *** Sent via Developersdex http://www.developersdex.com ***
> Don't just participate in USENET...get rewarded for it! 

-- 
Gerry Hickman (London UK)

Relevant Pages

  • Re: DAO vs ADO: question-1
    ... > Windows applications, to hand-held PC apps, to client/server applications, ... > is better application and database design. ... Switching from DAO to ADO is ... > both DAO and ADO all wait at the same speed. ...
    (microsoft.public.vb.database.ado)
  • Re: Database access sucks!
    ... > I don't agree with you about DAO though, you should NOT use DAO - it ... .Net changed a lot from DAO, ADO, and OLEDB. ... >> a Recordset object as it was in the older versions within .NET and it ... >> I've used other environments. ...
    (microsoft.public.dotnet.general)
  • Re: OpenRecordset fails
    ... Yes, but if ADO is included in the references, you have to 'dis-ambiguate' ... recordset object ... Both use DAO ...
    (microsoft.public.access.modulesdaovba)
  • Re: 97 to 2000 format
    ... > Both DAO and ADO have a Recordset object so I should have mentioned that in ... > addition to adding the reference for DAO you need to remove the one for ADO. ... > Dim rst as Recordset ...
    (microsoft.public.access.modulesdaovba)
  • Re: 97 to 2000 format
    ... Both DAO and ADO have a Recordset object so I should have mentioned that in ... addition to adding the reference for DAO you need to remove the one for ADO. ... Dim rst as Recordset ...
    (microsoft.public.access.modulesdaovba)