Re: Application using Jet provider

From: William \(Bill\) Vaughn (billvaRemoveThis_at_nwlink.com)
Date: 07/23/04

  • Next message: Ian Bayly: "Re: How to generate Word report using ADO - multiple pages per record"
    Date: Thu, 22 Jul 2004 20:07:14 -0700
    
    

    One of the primary reasons .NET was created was to eliminate the long litany
    of unsolvable problems you'll encounter with COM and JET. Sure, there are
    ways to work around these issues, but every course you take leads to other
    problems and can cause existing applications to fail.
    Yes the .NET Framework is large but most users already have it
    installed--it's one of the "recommended updates". In the future the
    framework will be part of the OS. Once it's installed, you have far fewer
    version issues to deal with than with the smaller COM components. The
    majority of serious development shops have either switched or are in the
    process of doing so.

    -- 
    ____________________________________
    William (Bill) Vaughn
    Author, Mentor, Consultant
    Microsoft MVP
    www.betav.com
    Please reply only to the newsgroup so that others can benefit.
    This posting is provided "AS IS" with no warranties, and confers no rights.
    __________________________________
    "Michael Byrne" <news@2paw.com> wrote in message
    news:OaRYR7BcEHA.2520@TK2MSFTNGP12.phx.gbl...
    > I have an application built in VB6 with an Access 2000 database using ADO
    > for data access.  It works well except when I think about releasing my
    next
    > version with database schema changes and thinking about how I need to
    > provide components with the installation.
    >
    > For example, what ADO version should I be using...are there compelling
    > arguments for different versions?  The SQL statements are rather
    > straight-forward so ADO 2.5 has worked fine so far.  I know you will say
    > "Use ADO 2.8" , however, I start to think about deployment to my
    customers.
    > Using ADOX (available from 2.7 on I believe) would make it easier to alter
    > the schema for upgrades, but I'm confused by what provider I would use if
    I
    > made MDAC 2.7 part of my InstallShield installation.  Or should MDAC be
    part
    > of my installation at all or just a system requirement???  (I want to make
    > it as fool-proof as possible for my customers since they may not be very
    > computer literate.)  What is common practice in that regard?
    >
    > For example, it seems that since MDAC 2.5, Microsoft Jet is no longer
    > included.  Does that mean I can no longer guarantee that I can use
    > "PROVIDER=MICROSOFT.JET.OLEDB.4.0;" and have that found on the users
    machine
    > if I only include MDAC 2.8 in my InstallShield installation???  Should I
    be
    > using a different provider if I am depending on ADO above 2.5??  Many of
    my
    > users have older machines and it's not out of the question to come across
    a
    > Windows 95 or NT.  It would be great to use the latest and greatest of all
    > components, but I was hoping that I could use components that would most
    > likely be present to reduce the chance for problems.
    >
    > My application itself is about 3M with exe,dll, database, files, etc.
    But,
    > my installation is now around 26M when I am including all the supporting
    > components (MDAC, XML 3.0, Jet 4.0, etc) to ensure they have everything
    they
    > need.  Am I using overkill in putting everything possible into the
    > installation?
    >
    > Also, I would develop the app in .NET, but then any customer that doesn't
    > have the .NET runtime has to download another 20M and install.  Just
    another
    > chance for something to go wrong.  This is probably the wrong forum for
    > that, but any thoughts on staying VB6 because there's less to install on
    the
    > users machine?
    >
    > So, summary of questions:
    >     - What version of ADO should I be using?
    >     - What provider should I be using?
    >     - With what MDAC installation could I be certain that both these would
    > be present?
    >     - Is Microsoft Jet as a provider a bad thing?  (Access database)  What
    > other options are there?
    >     - Would a system requirement such as having Office 2000 and IE 6.0 on
    > the machine alleviate any of these problems?  (Meaning I don't have to
    > include them in my install.  I do require IE 6.0 currently)
    >
    > Any thoughts or comments would be greatly appreciated.  Or even a place to
    > look that discusses deploying applications and what you should include for
    > each of these components.
    >
    > Thanks,
    > Michael
    >
    >
    

  • Next message: Ian Bayly: "Re: How to generate Word report using ADO - multiple pages per record"

    Relevant Pages

    • Application using Jet provider
      ... I have an application built in VB6 with an Access 2000 database using ADO ... made MDAC 2.7 part of my InstallShield installation. ...
      (microsoft.public.vb.database)
    • Application using Jet provider
      ... I have an application built in VB6 with an Access 2000 database using ADO ... made MDAC 2.7 part of my InstallShield installation. ...
      (microsoft.public.vb.database.ado)
    • Re: Which is the best single-user DB ?
      ... Jet SP is available from http://www.microsoft.com/downloads and Jet is ... installed on most computers even not being part of MDAC. ... There is also ODBC driver if you do not want to depend on ADO ... > Jet-Engine is DAO and no longer part of the MDAC installation, ...
      (borland.public.delphi.thirdpartytools.general)
    • Re: Application using Jet provider
      ... of unsolvable problems you'll encounter with COM and JET. ... > I have an application built in VB6 with an Access 2000 database using ADO ... > made MDAC 2.7 part of my InstallShield installation. ...
      (microsoft.public.vb.database)
    • Re: reinstall mdac & DAO problem
      ... Jet is not a part of MDAC installation starting MDAC 2.6. ... > MDAC 2.8 RTM is incompatible with this version of Windows. ...
      (microsoft.public.data.ado)

    Loading