How rreliable is the CLSID method of obtaining a file location?
in [Visual Basic]
|
Prev: problem emailing attachment with COD method
Next: Loading Excel via VB - Resize issue with over 255 characters in a
From: Randem on 8 Jul 2010 19:16 Ok, I guess the underlying question is why does one need to know which of these version are installed. I remember MS had a tool to attempt to verify this same thing and the tool came up with different versions installed due to mis-matched version being installed. I would think that you would just install the version you need and be done with it. What am I missing here? -- The Top Script Generator for Jordan Russell's Inno Setup - http://www.randem.com/innoscript.html Free Utilities and Code - http://www.randem.com/freesoftutil.html "Tony Toews" <ttoews(a)telusplanet.net> wrote in message news:esea3611q3nq5re7nnc77u7f1lk6c5bksd(a)4ax.com... > Folks > > I'm wanting to determine the version of various DAO, MSJet, ACE and > ADO DLLs. > > One means of doing this is by using a CSIDL to get to C:\Program > Files\Common Files\system\ado\msado15.dll (or close and then adding > on system\ado as requiired.) > > Elsewhere it has been suggested that I should use the CLSID. In this > case the entire key is > HKEY_CLASSES_ROOT\CLSID\{00000535-0000-0010-8000-00AA006D2EA4}\InprocServer32 > which I got from http://support.microsoft.com/kb/266668 > > Is this a relable method especially if dealing with other language > OSs? Is this the best, recommended method? > > Tony > -- > Tony Toews, Microsoft Access MVP > Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm > Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ > For a convenient utility to keep your users FEs and other files > updated see http://www.autofeupdater.com/
From: Kevin Provance on 8 Jul 2010 21:13 "Randem" <newsgroups(a)randem.com> wrote in message news:edf8WOvHLHA.1660(a)TK2MSFTNGP04.phx.gbl... : : Ok, I guess the underlying question is why does one need to know which of : these version are installed. I remember MS had a tool to attempt to verify : this same thing and the tool came up with different versions installed due : to mis-matched version being installed. : : I would think that you would just install the version you need and be done : with it. What am I missing here? Humility, and a basic understanding of interface design.
From: Tony Toews on 8 Jul 2010 23:44 On Thu, 08 Jul 2010 18:11:44 -0500, ralph <nt_consulting64(a)yahoo.net> wrote: >[Note: As I know exactly squat about your problem domain, what follows >can be safely ignored. <g>] This is for my Auto FE Updater utility which is in use by many different organizations around the world. >Probably better and certainly easier is simply require all users to be >using the latest 'n greatest for ADO and DAO. Basically I want to present the developer who is using my tool with all the versions present that the users are using. So they can decide if there is a problem somewhere. >ACE/Jet will depend on the version of Office/MSAccess installed. >So far ACE seems to be maintaining decent backward compatibility. >There may be a need to support Jet components previous to 2000, but >again that would be only for legacy Apps. Most of the start method options in my utility start up MS Access by interrogating the registry in one fashion or another and locating the exact path to msaccess.exe. I then look at the first component of the msaccess.exe version and decide which ACE/Jet version to look up. As I do have A97 installed, and a few folks out there are still using it I choose to go that far back in my logic and do log DAO 3.5/Jet 3.5. >I would think a simple track of the O/S and the Office/MSAccess >version installed on the Users box would be sufficient to diagnosis >most problems that might appear. I'm a paranoid pessimist. >Some users may need to support special legacy situations - you could >make a comment for the exceptions. If someone is still using A2.0 out there and asks me and if I come across my A2.0 disks which are archived to a CD/DVD somewhere then I"ll install it. And spend the 10 or 20 minutes to go through the coce to support it. But I expect the chances of that to be quite small. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/
From: Tony Toews on 8 Jul 2010 23:45 On Thu, 8 Jul 2010 13:16:31 -1000, "Randem" <newsgroups(a)randem.com> wrote: >Ok, I guess the underlying question is why does one need to know which of >these version are installed. I remember MS had a tool to attempt to verify >this same thing and the tool came up with different versions installed due >to mis-matched version being installed. > >I would think that you would just install the version you need and be done >with it. What am I missing here? Because my utility is in use by a large number of organizations. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/
From: Tony Toews on 8 Jul 2010 23:45
On Thu, 8 Jul 2010 21:13:59 -0400, "Kevin Provance" <k(a)p.c> wrote: >: I would think that you would just install the version you need and be done >: with it. What am I missing here? > >Humility, and a basic understanding of interface design. Please explain more. Both the humility and the interface design part. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/ |