"Ralph" wrote:

>
> "Dan" <D**@discussions.microsoft.com> wrote in messag
> news:C10FC3A9-1FD4-4A5B-AA46-B645BEE67DE8@microsoft.com...
> > Hi  -
> >
> > Does anyone know if the MDAC or Jet version loaded on a machine affect how
> > an app is compiled when creating an executable, or are they external to
> the
> > executable, but required for it to work correctly?
> >
> > Thanks for any help!
> >
> > Dan
>
> There is no way to give a complete description of these components in this
> forum.
> You really need to peruse your MSDN CD, the website, or perhaps better get
> an advanced VB book.
>
> The following might help to get you started. (Obviously overly simplied.)
>
> These components are all either ActiveX components ('COM') or are OLE
> components that support 'COM' on a Windows platform. They are meant to be
> universally shared.
>
> [It should be noted that COM is a 'specification' and OLE is MS's internal
> proprietary implementation of COM. Although the term 'COM' is often used as
> the generic term for the whole process.]
>
> [Also ActiveX components can exists in a wide variety of different types of
> services - a library, a control, a server, an executable, &etc.  I will use
> the general terms of 'library' or 'dll' for a COM component.]
>
> A 'COM' component is one that publishes various COM interfaces. A cardinal
> rule of COM is once an interface is published the public properities that
> define that interface and the GUIDs and ProgIDs that identify it - NEVER
> changes. The code behind, the component that supports it, and anything that
> component uses may change but never the interface.
>
> How this affects your application (a COM client)...
>
> First, a COM component is never 'compiled-into' your application. (Don't
> confuse this with various libraries that do provide multiple versions - a
> statically linked one and one that can be dynamically linked.) VB doesn't
> support this - all external libraries are dynamically linked in VB.
>
> A COM client can use COM in one of two ways - by specifing the exact
> ClassID, LibID, TypeLib, IID, through a GUID, or by ProgID (a string
> 'name'). [carefully avoiding going into alternate ways to specify a 'name'.
> <g>)
>
> If using the latter to make a call to a library COM will use the registry to
> seek out that name to see if it is available, and if so match that request
> to whatever libraries are present that published that ID. It is important to
> note that many common COM libraries use the same ProgIDs through out its
> career. ADO for example is "ADODB". This is termed "late binding" and simply
> means your application will get whatever version of that library that is
> loaded on your system.
>
> This instruments code in your app that seeks out a suitable library at
> runtime and thereafter checks all calls to that library to see if it is
> supported. You can only debug or know if your application works at runtime.
>
> If your app uses late binding then it will 'usually' work on any platform
> that has "ADODB" installed. I say 'usually' because you can obviously run
> into trouble if you use advanced features of one version in your code and
> then install on a machine with earlier versions.
>
> The other method is where you explicitly declare the exact typelib or
> interface that your application is going to connect to in your code. Each
> version for ADO for example, publishes a unique typelib or interface for
> that version. This is "early binding", the advantage is you get complete
> type-checking, call resolution, during compile-time. The disadvantage is
> your App can only work with the exact Interface you defined at compile-time,
> therefore if you compiled with ADO 2.6, for example, the target machine must
> have registered the "ADO 2.6" library on the target box.
>
> It should be noted that the exact component (the file, dll, or disk image)
> is not important only that that component supports a particular library
> (published interface). Versions of MDAC are labeled with the highest version
> of ADO supported, but also contain all the interfaces previously published.
>
> So your machine might have "MDAC 2.8" installed and you compiled against ADO
> 2.6. The target machine might have "MDAC 2.7" installed, but it will support
> your app because those components also support ADO 2.6.
>
> The "fly in the ointment" with this scenario is the OLE components.
> Different platforms and different versions of products perform best when
> using a particular suite.
>
> Whew! Sorry I didn't mean to go so far out around the barn and back. <g>
>
> What I am trying to point out that there is no simple answer to your
> question. It depends on how it was compiled (late or early) and what
> components are available at runtime. It is essentially a very simple
> process, however with a few 'gotchas'. <g>
>
> -ralph
>
>
>

"Dan" <D**@discussions.microsoft.com> wrote in message
news:D6CF5BEA-846E-4F43-8DB9-5F0CE73F9087@microsoft.com...
> Thanks Ralph...
>
> You certainly gave me an earful!  I will take your advice and read up on
> that.  These compatibity/version management issues can be a real headache.
> My app works fine on W2K but not XP, and I'm pretty sure it has something
to
> do with MDAC or Jet version mismatch.  I'm not doing anything fancy - just
> programmatically opening up Excel, reading some cells, and storing them in
a
> table in an Access 2000 mdb file.  Not rocket science by any means!  This
> compatibility issue though has grinded this project to a halt!
>
>
>
>
>
> "Ralph" wrote:
> <snipped>