Re: Question on creating an executable
- From: Dan <Dan@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 9 Jul 2005 13:05:04 -0700
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:
>
> "Dan" <Dan@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in messag
> news:C10FC3A9-1FD4-4A5B-AA46-B645BEE67DE8@xxxxxxxxxxxxxxxx
> > 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
>
>
>
.
- Follow-Ups:
- Re: Question on creating an executable
- From: Ralph
- Re: Question on creating an executable
- References:
- Question on creating an executable
- From: Dan
- Re: Question on creating an executable
- From: Ralph
- Question on creating an executable
- Prev by Date: Re: Question on creating an executable
- Next by Date: Re: Write to CD-RW from VB 6.0 SP5
- Previous by thread: Re: Question on creating an executable
- Next by thread: Re: Question on creating an executable
- Index(es):
Relevant Pages
|
