Re: MDAC question
From: Ralph (nt_consulting32_at_hotmail.com)
Date: 04/13/04
- Next message: Jeff Johnson [MVP: VB]: "Re: P2P using VB- is it possible?"
- Previous message: Murray Taylor: "Component Conflicts"
- In reply to: MikeD: "Re: MDAC question"
- Next in thread: Bonj: "Re: MDAC question"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 13 Apr 2004 11:20:49 -0500
"MikeD" <nobody@nowhere.edu> wrote in message
news:e23kYrOIEHA.3032@TK2MSFTNGP09.phx.gbl...
>
> "Ralph" <nt_consulting32@hotmail.com> wrote in message
> news:JfKdnbExSsYeaefdRVn-vg@arkansas.net...
> >
> > "mcnewsxp" <mcourter@mindspring.com> wrote in message
> > news:e5KaUfJIEHA.3432@tk2msftngp13.phx.gbl...
> > > is it possible to remove 2.8 and rollback to a previous version of
MDAC
> or
> > > is it possible to have version 2.8 on a development PC but release
EXEs
> > with
> > > 2.7 SP1 refresh?
> > > need to know PDQ so may post elsewhere.
> > > thanks,
> > > mcnewsxp
> > >
> >
> > You can install all or a select few of the MDAC 'versions' on any
machine.
>
> I don't know what you mean by that statement.
>
It simply means that if you have, for example, the mdac_typ.exe for 2.5
and the mdac_typ.exe for 2.7, you can install both if you wish with
negligible impact. (Obviously, it is best to install the earlier version
first)
MDAC installations have always been a bit confusing because the releases
contain both bug fixes (maintenance) and enhancement upgrades. Also they
were meant to be 'universal' and provide multiple data access 'protocols'
for multiple M$ applications, platforms, and products, vb's programming
needs or even ADO being only one of them. As such they should always be
treated as more of a o/s upgrade and NOT simply the sole dependancy of any
application.
Within the COM World, amidst the seemingly endless opportunities for
"DLL HELL", M$'s MDACs, the Univeral Data Access components, are an amazing
success story. While I am sure that any of us that have worked with data
access over the years can come up with an occasional war story, over-all
they are comparably the most stable and reliable object library M$ ever
released. Whenever there has been any difficulty, at least in my experience,
it can always be traced back to some administrator or programmer trying to
get cute with versioning or a failure to keep the components up todate.
> > You can uninstall any or all versions.
>
> Not via "normal" means, i.e. Add/Remove Programs or an uninstall shortcut.
>
True. I should have been less flippant.
I use a combination of 3rd party install monitors and images to control
production, test boxes, and development environments and tend to forget
others probably don't.
What I really meant to convey was the simple fact that if one wants to
not use a newer version - then just ignore it and don't use it. The
components once installed provide essentially a Data Access "stack" where
one can simply chose which version, library or protocol to use for a
particular application. Except in a very few cases - it simply is not
necessary to remove older versions.
By the way, a simple method to "revert" is to reinstall an earlier MDAC
version and answer 'no' to keeping the newer DLLs.
> >
> > However, the version the application is compiled with will be the
version
> > that needs to be distributed with the application. (However, IMHO I
> wouldn't
> > distributed the MDAC components as part of the application setup -
rather
> I
> > would just distribute the mdac_typ.exe along with my setup.)
>
> That I agree with.
>
> >
> > To 'roll-back' any application to a former version just reselect the ADO
> > version in the project references.
> >
> > So yes you can have 2.8, 2.7, 2.5, ... on your development machine and
> > simply select which version you want to compile the application with.
>
> Not really. I wasn't really clear about this in my original answer
either.
> If you have MDAC 2.8 installed, you can choose to reference a *type
library*
> for a previous version of MDAC. But you're still actually using the 2.8
> file version of ADO (msado15.dll). It's really best NOT to install a
higher
> version of MDAC than you plan to use during development.
>
It is true that 2.7 and 2.8 'share' the same DLL (the other versions,
2.0, 2.1, ... have separate DLLs). The reason for this, AFAIK, is because
there are major fixes contained in msado15 that effects 2.7 as well as
provides a newer 2.8 interface. M$ also doesn't recommend blindly using the
2.8 interface for all application, but rather staying with 2.7 unless you
truly need some of the 2.8 enhancements (details on their website), however
they do recommend upgrading to the most current the msado15.dll, if
possible, to obtain the repairs for 2.7.
Which brings up one of the oldest dilemmas in software development -
When do you upgrade? Considering that the newer MDACs often not only
provided some 'repairs' for older versions as well offering a newer
interface, it appears to be a no-brainer. IMHO, using the latest 'n greatest
is usually the best policy. Keeping the OS up to date is a very proactive
way to resolve a lot of problems.
However, there are environments where because an application is
considered a critical mission or is a financial program subject to audit -
just upgrading in a willy-nilly fashion is just not acceptable. In which
case it is absolutely necessary to establish tight controls for both the
production and development environments. Another reason, as I mentioned
above, to ALWAYS treat an MDAC upgrade as a operating system upgrade - NOT
as a single application upgrade. You must consider the actual version of the
individual components and not just the particular 'interface' supported.
I have always successfully upgraded to the most current MDAC, thru all
versions, in multiple client environments with never a major impact. That is
not to say that someone else's mileage might not vary. It is a big world out
there.
So in general I would have to disagree with your last statement. Unless
you are involved with one of the exceptions I noted above, IMHO, it is best
to always install and use the most current MDAC kit available from M$.
But that is just my opinion and I am often wrong. <g>
> Mike
>
>
- Next message: Jeff Johnson [MVP: VB]: "Re: P2P using VB- is it possible?"
- Previous message: Murray Taylor: "Component Conflicts"
- In reply to: MikeD: "Re: MDAC question"
- Next in thread: Bonj: "Re: MDAC question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
