DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 4 of 4

Thread: Re: A VBer's Strategy -- ADO

  1. #1
    Jeff Johnson Guest

    Re: A VBer's Strategy -- ADO


    When faced with the ADO question in Access 2000, I chose to stick with DAO.
    (If it ain't broke, don't fix it....) That's annoying that ADO didn't turn
    out to the the "wave of the future," but at least I didn't waste a lot of
    time with it....

    If we're using C++ for data access and we want our code to be as cross-platform
    and long-lived as possible, then what's the best handle database access?
    (This is assuming that the three letter acronyms are gonna keep coming....)


    Can you do this sort of thing on Linux or the Mac??:

    #include <adonet.h> /*


    What is the cost of NOT learning ADO.NET? I'm willing to try something more
    "archaic" if it won't be outmoded/useless in a couple years.... Or is there
    really no alternative if you want to be sure your program can get connected
    to SQL Server?





    "Larry Linson" <larry.linson@ntpcug.org> wrote:
    >"Jeff Johnson" wrote
    >
    > > * Rig your objects to talk to the database via ADO.

    >
    >"Original ADO" is deader than the proverbial doornail -- it turned out to

    be
    >just the latest in the long string of "access methods of choice for the
    >foreseeable future" that have been tossed aside in favor of "new technology"
    >after one or two releases. It's right there in the Redmond "Forgotten
    >Things" closet with RDO, ODBC API, and several others whose initials even

    I,
    >a qualified "techno-retro-grouch", have forgotten because they simply
    >weren't around long enough for us to "learn to love them". ADO.NET is built
    >on a different model, isn't programmed the same, and isn't even based on

    OLE
    >DB. You won't gain much by using it.
    >
    >However, many, many people (talented, experienced, and sophisticated
    >developers, BTW) have indicated to me that using it with VB or Access, they
    >encountered an advanced, sophisticated, and [unsolvable | solvable only

    with
    >heroic effort | very difficult to solve] version of DLL ****. I gave three
    >choices depending on why they were trying to use it, and how committed they
    >were to learning it. If they were trying to solve a business problem, they
    >quickly forgot about ADO, used DAO, Jet, and linked tables and got on with
    >their business; if they had a compelling need to learn ADO for some reason,
    >then a few were willing to expend the heroic effort.
    >
    >



  2. #2
    Larry Linson Guest

    Re: A VBer's Strategy -- ADO

    Interestingly, I see your reply with a quote from my previous response, but
    don't see my previous response. Hmm.

    I didn't understand your original to say ADO.NET, but ADO. I don't think
    you'll be one inch ahead of the game using "original ADO" instead of DAO,
    because of the differences between "original ADO" and ADO.NET. Of course, if
    DAO is not installed on the server where your database is located, then ADO
    becomes not a "choice" but a "given" for your database-access Objects. (And,
    of course, using a three-tier approach would be quite a change for people
    like me, whose clients' needs have been satisfactorily addressed with
    straight, two-tier client-server. N-tier is appropriate for some
    applications, but it isn't "the one single approach that should be used by
    everyone on all applications" as reading some of the hype would lead one to
    believe.)

    On looking at your first post again, I'd also take strong exception to
    "Write your GUIs in VB.NET". Under no circumstances would I create
    applications vital to my business with BETA code, nor would I advise my
    clients to create or use such applications. In fact, given a certain
    vendor's abysmal record with first and even second releases, Version 2, SR 2
    (if the feedback is good) might be a reasonable point to consider using it.
    If, due to the uncertainty, one hasn't converted to another methodology in
    the meanwhile -- I won't mention any *-words as alternatives in the interest
    of avoiding yet another flamewar.

    I do agree that, absent some serious about-faces by The Boys and Girls in
    Redmond, classic VB is dying, and the pulse of VBA is not strong. I do
    predict that "defections" by the people who depend on both and are not in
    the humungous-app market will be significant. And, it's my gut-feel that
    there are more of us than Microsoft seems to realize. Perhaps, though, they
    do realize and just realize that we aren't, under any conditions, likely to
    expedite their vision of all apps delivered over the net by subscription or
    microcharging by megacorps.

    My prediction is that, although I do not now know who it will be, someone
    will step in to satisfy an unfilled market need. Since all the "big guys"
    seem to be pursuing the same vision as Microsoft, we may not necessarily be
    familiar with the corporate identity who'll show up to do so.

    The OpenSource community, mostly, from what I read, seems to think that Mono
    is a last desperate stab at shoring up the GNOME project, not a serious
    development effort. So it may be from the OpenSource community that someone
    will rise to "fill the need". After all, a few years ago, who'd ever have
    given a second thought to a "free O/S" making the inroads, server-side, that
    Linux has?

    "Jeff Johnson" <johnsonjs@hotmail.com> wrote in message
    news:3b604b37$1@news.devx.com...
    >
    > When faced with the ADO question in Access 2000, I chose to stick with

    DAO.
    > (If it ain't broke, don't fix it....) That's annoying that ADO didn't

    turn
    > out to the the "wave of the future," but at least I didn't waste a lot of
    > time with it....
    >
    > If we're using C++ for data access and we want our code to be as

    cross-platform
    > and long-lived as possible, then what's the best handle database access?
    > (This is assuming that the three letter acronyms are gonna keep

    coming....)
    >
    >
    > Can you do this sort of thing on Linux or the Mac??:
    >
    > #include <adonet.h> /*
    >
    >
    > What is the cost of NOT learning ADO.NET? I'm willing to try something

    more
    > "archaic" if it won't be outmoded/useless in a couple years.... Or is

    there
    > really no alternative if you want to be sure your program can get

    connected
    > to SQL Server?
    >
    >
    >
    >
    >
    > "Larry Linson" <larry.linson@ntpcug.org> wrote:
    > >"Jeff Johnson" wrote
    > >
    > > > * Rig your objects to talk to the database via ADO.

    > >
    > >"Original ADO" is deader than the proverbial doornail -- it turned out to

    > be
    > >just the latest in the long string of "access methods of choice for the
    > >foreseeable future" that have been tossed aside in favor of "new

    technology"
    > >after one or two releases. It's right there in the Redmond "Forgotten
    > >Things" closet with RDO, ODBC API, and several others whose initials even

    > I,
    > >a qualified "techno-retro-grouch", have forgotten because they simply
    > >weren't around long enough for us to "learn to love them". ADO.NET is

    built
    > >on a different model, isn't programmed the same, and isn't even based on

    > OLE
    > >DB. You won't gain much by using it.
    > >
    > >However, many, many people (talented, experienced, and sophisticated
    > >developers, BTW) have indicated to me that using it with VB or Access,

    they
    > >encountered an advanced, sophisticated, and [unsolvable | solvable only

    > with
    > >heroic effort | very difficult to solve] version of DLL ****. I gave

    three
    > >choices depending on why they were trying to use it, and how committed

    they
    > >were to learning it. If they were trying to solve a business problem,

    they
    > >quickly forgot about ADO, used DAO, Jet, and linked tables and got on

    with
    > >their business; if they had a compelling need to learn ADO for some

    reason,
    > >then a few were willing to expend the heroic effort.
    > >
    > >

    >




  3. #3
    Bob O`Bob Guest

    Re: A VBer's Strategy -- ADO

    Larry Linson wrote:
    >
    > Interestingly, I see your reply with a quote from my previous response, but
    > don't see my previous response. Hmm.


    It's still being served.
    Your news client just isn't making it easy to naviagate to.
    Try this link syntax:
    <news://news.devx.com/3b6036fb%241@news.devx.com>



    Bob
    --
    I always knew Microsoft had plenty of bullets.
    But I never had any idea it had so many feet.

  4. #4
    Steve Dee Guest

    Re: A VBer's Strategy -- ADO

    Jeff,
    well...your question hits a lot of areas. Java folks would say to use
    JDBC...but that's just a clone of ODBC with warts. OLE DB and ODBC still
    have the best cross platform availability and are more mature
    implementations...of course Oracle will say that OCI is the savior, but
    well...**** you use it and then you decide....but I will say that it's like
    programming with straight ODBC SDK, except Oracle is a tad on the cavalier
    side about datatypes and compiler errors. Not very strongly typed and very
    sloppy. Then again, I have not used straight OCI for a while, so maybe they
    cleaned up their act.

    The best way to handle database access is EXACTLY what .Net is doing.
    ADO.Net is NOT throwing out "classic ADO". MS just realized that ODBC and
    especially OLE DB, while a great idea, was not being adopted by non COM type
    OS's. ADO.Net is the same idea, but using XML. Yeah, the model has
    changed...but not as drastic as some would make out, and definately for the
    better.

    "Jeff Johnson" <johnsonjs@hotmail.com> wrote in message
    news:3b604b37$1@news.devx.com...
    >
    > When faced with the ADO question in Access 2000, I chose to stick with

    DAO.
    > (If it ain't broke, don't fix it....) That's annoying that ADO didn't

    turn
    > out to the the "wave of the future," but at least I didn't waste a lot of
    > time with it....
    >
    > If we're using C++ for data access and we want our code to be as

    cross-platform
    > and long-lived as possible, then what's the best handle database access?
    > (This is assuming that the three letter acronyms are gonna keep

    coming....)
    >
    >
    > Can you do this sort of thing on Linux or the Mac??:
    >
    > #include <adonet.h> /*
    >
    >
    > What is the cost of NOT learning ADO.NET? I'm willing to try something

    more
    > "archaic" if it won't be outmoded/useless in a couple years.... Or is

    there
    > really no alternative if you want to be sure your program can get

    connected
    > to SQL Server?
    >
    >
    >
    >
    >
    > "Larry Linson" <larry.linson@ntpcug.org> wrote:
    > >"Jeff Johnson" wrote
    > >
    > > > * Rig your objects to talk to the database via ADO.

    > >
    > >"Original ADO" is deader than the proverbial doornail -- it turned out to

    > be
    > >just the latest in the long string of "access methods of choice for the
    > >foreseeable future" that have been tossed aside in favor of "new

    technology"
    > >after one or two releases. It's right there in the Redmond "Forgotten
    > >Things" closet with RDO, ODBC API, and several others whose initials even

    > I,
    > >a qualified "techno-retro-grouch", have forgotten because they simply
    > >weren't around long enough for us to "learn to love them". ADO.NET is

    built
    > >on a different model, isn't programmed the same, and isn't even based on

    > OLE
    > >DB. You won't gain much by using it.
    > >
    > >However, many, many people (talented, experienced, and sophisticated
    > >developers, BTW) have indicated to me that using it with VB or Access,

    they
    > >encountered an advanced, sophisticated, and [unsolvable | solvable only

    > with
    > >heroic effort | very difficult to solve] version of DLL ****. I gave

    three
    > >choices depending on why they were trying to use it, and how committed

    they
    > >were to learning it. If they were trying to solve a business problem,

    they
    > >quickly forgot about ADO, used DAO, Jet, and linked tables and got on

    with
    > >their business; if they had a compelling need to learn ADO for some

    reason,
    > >then a few were willing to expend the heroic effort.
    > >
    > >

    >




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center