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: Tony Toews on 8 Jul 2010 17:28 On Thu, 08 Jul 2010 06:18:38 -0500, ralph <nt_consulting64(a)yahoo.net> wrote: >By maintaining a list of GUIDS (CLSIDs, ...), AppID/ProgIDs, and >interesting stats of the various components (builds, size, date, ...) >you can build an assortment of methods of interrogate the Registry and >files to derive this information, but I have to ask ... Why? I just want to log the version numbers for all the users for my utility. This way the devs can be sure that everyone is on a current version. Which is ery likely given that DAO/Jet/ADO is part of the OS but still. >In other words what are you plannning on doing if the current versions >are something less or something greater than what you want to see? Just log and display the version number in an Access database. 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: Karl E. Peterson on 8 Jul 2010 17:58 After serious thinking Tony Toews wrote : > On Thu, 08 Jul 2010 14:53:13 -0500, Paul Clement > <UseAdddressAtEndofMessage(a)swspectrum.com> wrote: > >> . I did not find any CLSIDs that referenced msado15.dll directly. > > That's puzzling because ADO is part of WIndows OS since 2000. > >> My >> understanding is that the interfaces are registered through the ADO version >> specific type libraries. > > When you look at the ADO references there are multiple references > available as I'm sure you've noticed. All but the most recent > reference are TLBs. The most recent is to the msado15.dll. You gotta remember, Paul's just here as an Agent of FUD. -- ..NET: It's About Trust! http://vfred.mvps.org
From: Tony Toews on 8 Jul 2010 18:52 On Thu, 08 Jul 2010 15:26:12 -0600, Tony Toews <ttoews(a)telusplanet.net> wrote: >That's puzzling because ADO is part of WIndows OS since 2000. Actually that should be ".... ADO is part of MDAC which is part of the Windows OS ...." 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 18:53 On Thu, 8 Jul 2010 05:54:46 -0400, "Nobody" <nobody(a)nobody.com> wrote: >> I'm wanting to determine the version of various DAO, MSJet, ACE and >> ADO DLLs. > >For ADO, you can check Version property of the Connection object. Ah, interesting. I'll check that out. 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: ralph on 8 Jul 2010 19:11
On Thu, 08 Jul 2010 15:28:02 -0600, Tony Toews <ttoews(a)telusplanet.net> wrote: >On Thu, 08 Jul 2010 06:18:38 -0500, ralph <nt_consulting64(a)yahoo.net> >wrote: > >>By maintaining a list of GUIDS (CLSIDs, ...), AppID/ProgIDs, and >>interesting stats of the various components (builds, size, date, ...) >>you can build an assortment of methods of interrogate the Registry and >>files to derive this information, but I have to ask ... Why? > >I just want to log the version numbers for all the users for my >utility. This way the devs can be sure that everyone is on a current >version. Which is ery likely given that DAO/Jet/ADO is part of the >OS but still. > [Note: As I know exactly squat about your problem domain, what follows can be safely ignored. <g>] Probably better and certainly easier is simply require all users to be using the latest 'n greatest for ADO and DAO. As all development has essentially stopped this will be ADO 2.8 (DAC 6) and will support all ADO versions from 2.5 and up. DAO is slightly different as there are separate components for each version. A user may have previous versions of DAO 3.6 installed to support legacy apps, but this should have little impact on your utility. 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. >>In other words what are you plannning on doing if the current versions >>are something less or something greater than what you want to see? > >Just log and display the version number in an Access database. > 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. Some users may need to support special legacy situations - you could make a comment for the exceptions. -ralph |