Registry setting for Access (1 Viewer)

[tadropik]

Is there a registry setting that tells me what version of Access is installed on a Windows computer?

 

[boblarson]

There is a registry setting of course when Access is installed. However, from where are you needing this? How are you going to use it? Those are some questions which can have a bearing on what exactly you need to get.

 

[tadropik]

I actually found what I was looking for. I have a Freeware install application that allows me to start my access application after it installs it.

The install application requires that I include the path to the MSACESS.EXE executable in order to run my access application.

The version on access varies on my clients computers.

I am able to read the following registry key to get that path:
HKEY_LOCAL_MACHINE
SOFTWARE
Microsoft
Windows
CurrentVersion
App Paths
MSACCESS.EXE Path = C:\Program Files\Microsoft Office\Office12\
(Deafult) = C:\PROGRA~1\MICROS~2\Office12\MSACCESS.EXE

Thanks for your reply.

 

[Dairy Farmer]

I feel like I'm posting the same comment in every other thread.

Forget which version of Access a user has. Or even if they have Access installed on their computer. It doesn't matter.

If you are designing your app in 2007 or 2010 then just package your app to run under Runtime.

For more details see "Introduction to the Access 2007 Developer Extensions and Runtime" in the Access help.

 

[boblarson]

I feel like I'm posting the same comment in every other thread.

Forget which version of Access a user has. Or even if they have Access installed on their computer. It doesn't matter.

Umm - yes it could. If you have users who have only 2003 and you have a database with custom menus/toolbars or specific code/or items that only work with 2007 (like pulling data from databases and you want to include Accdb formats for the user to be able to choose from, or Excel 2007 files (xlsm, xlsx, etc.), then you can't use that code for 2003. Or if you had a custom ribbon and wanted to load it for 2007 users and a custom toolbar/menu for 2003 users, you could.

If you are designing your app in 2007 or 2010 then just package your app to run under Runtime.

That is good to a point but it depends on why they need to know which version it is whether that solution will work for them or not. As mentioned above, there ARE instances where you might need to know which version you have so you can enable different features.

 

[Dairy Farmer]

The Access 2007 Runtime is a redistributable program that allows people who do not have Access 2007 installed on their computers to use Access 2007 database applications.

You can create a custom Ribbon, and then associate that Ribbon with a form or report. You cannot expose the default Ribbon tabs in runtime mode.

No more creating 2 db's with 2 sets of code and 2 sets of custom menus. Even to the extreme of 2 sets of help files with 2 sets of screen shots. Or having to test the app on 2 computers (or on a virtual computer) to see if the 2003 version works. Your client requests a change or submits a bug report and off you go again. Double the work. As a client I'm not going to pay you twice to do the same thing.

By using Runtimes you are giving the user the benifit of the newer version without the cost of upgrading.

If the user has 97, 2000 or 2003 they still get the look and feel of 2007 and can run your 2007 app as if they have Access 2007 installed. They just can't build or edit the structure of the app.

As far as working with other Office apps, there are plenty of work arounds. a small price to pay.

 

[boblarson]

No more creating 2 db's with 2 sets of code and 2 sets of custom menus. Even to the extreme of 2 sets of help files with 2 sets of screen shots. Or having to test the app on 2 computers (or on a virtual computer) to see if the 2003 version works. Your client requests a change or submits a bug report and off you go again. Double the work. As a client I'm not going to pay you twice to do the same thing.

By using Runtimes you are giving the user the benifit of the newer version without the cost of upgrading.

If the user has 97, 2000 or 2003 they still get the look and feel of 2007 and can run your 2007 app as if they have Access 2007 installed. They just can't build or edit the structure of the app.

As far as working with other Office apps, there are plenty of work arounds. a small price to pay.

All of that is good, but you still need to know which version a customer is using if they REFUSE to install the runtime. I know plenty of corporate settings which would simply say NO and so you are stuck running whatever previous version they have until they decide you can do that.

So, AGAIN, I will state that your answer is TOO SIMPLISTIC and even wrong in some circumstances. It all depends upon what the end users can do and what resources they can use. So, if you build something for more than one company, you could need to know which version is running it and work accordingly.

 

[gemma-the-husky]

the other point, of course is that multiple versions of access can reside together on a PC

you could do a dir for the programme MSAccess.exe. I think these are correct. it's tricky though, as access is "smart" - so you can't even use file associations - as somehow, access tries to open any database with the last version of access you used.

access97 = c:\program files\microsoft office\office
access2002/XP = c:\program files\microsoft office\office10
access2003 = c:\program files\microsoft office\office11
access2007 = c:\program files\microsoft office\office12
access2010 = c:\program files\microsoft office\office14

 

[Galaxiom]

access97 = c:\program files\microsoft office\office
access2002/XP = c:\program files\microsoft office\office10
access2003 = c:\program files\microsoft office\office11
access2007 = c:\program files\microsoft office\office12
access2010 = c:\program files\microsoft office\office14

What happened to Office13 ?

Is Microsoft actually superstitious?

 

[gemma-the-husky]

possibly - thats where they go though, as I am sure you know!

 

[boblarson]

access97 = c:\program files\microsoft office\office
access2002/XP = c:\program files\microsoft office\office10
access2003 = c:\program files\microsoft office\office11
access2007 = c:\program files\microsoft office\office12
access2010 = c:\program files\microsoft office\office14

That is, if the DEFAULT installation path is chosen. But it may not have been, so you need the registry entries to ensure the correct path.

 

[accesslearner]

That is, if the DEFAULT installation path is chosen. But it may not have been, so you need the registry entries to ensure the correct path.

Could you let me know if there is a way we can by pass the version problem in Access. I have access 2007 running in office 2003 and so there is always a library incompatility issue were i go to the script and add references and select office 2003 library, word, outlook excel etc.. and the application runs. I need to do this across a group and to a lot of users. can i automate this process. Detect what version is on the user machine and based on the office version install the corresponding library files so it does not generate a reference error.

thanks

 

[boblarson]

Could you let me know if there is a way we can by pass the version problem in Access. I have access 2007 running in office 2003 and so there is always a library incompatility issue were i go to the script and add references and select office 2003 library, word, outlook excel etc.. and the application runs. I need to do this across a group and to a lot of users. can i automate this process. Detect what version is on the user machine and based on the office version install the corresponding library files so it does not generate a reference error.

thanks

The problem is that you are using EARLY binding for whatever you are using. If you do that you MUST set the references from the version you are going to use if you are working on the file in a later version. If you use LATE BINDING then you can use your code WITHOUT selecting the Office 2003 references.

For example, if you have code with

Dim appXL As Excel.Application
Dim xlWB As Excel.Workbook

then you would need to change to

Dim objXL As Object
Dim objWB As Object

And then to create the object you use

Set objXL = CreateObject("Excel.Application")

The same goes for all of the various things like Outlook, etc.

 

[accesslearner]

Thanks for your prompt reply Bob,


I am new to coding. From what i understand

Dim objXL As ObjectDim objWB As ObjectSet objXL = CreateObject("Excel.Application")
by creating this late binding reference can i by-pass the use of the library file reference. ie. since i run access 2007 with office 2003 do i not need to let access know that i need to check my office 2003 library in order to work. Manually i would have to browse through

access97 = c:\program files\microsoft office\office
access2002/XP = c:\program files\microsoft office\office10
access2003 = c:\program files\microsoft office\office11
access2007 = c:\program files\microsoft office\office12
access2010 = c:\program files\microsoft office\office14

and go to the appropiate version of the access and check the compatible library file excel, work file and check it off.

so programatically do i have to
first check the version of access running
then check the office version running
and then programatically check the right library files to run.
I do apologise if this sounds like really basic but i am trying to figure out how to go about doing this, since i need to run this application across different user machines. And no two users run the same office application.

 

[boblarson]

No, if you use LATE BINDING you need NO code to check versions and you do not need to check any Office references AT ALL.

 

[gemma-the-husky]

No, if you use LATE BINDING you need NO code to check versions and you do not need to check any Office references AT ALL.

if you use late binding, and you don't set a reference to the appropriate library - then if you use a function from the library - how does the app compile without an error? I never understood this.

 

[boblarson]

if you use late binding, and you don't set a reference to the appropriate library - then if you use a function from the library - how does the app compile without an error? I never understood this.

In order to use a function from the applicable library you would need to reference it with the upper level application object you create. It compiles because it isn't calling anything at that point. It may not run if you don't do it correctly, which is why many times I will set the references and use EARLY binding for development but change it over to LATE binding for production. Then I need not worry about versioning problems, unless I'm using something from a later version which doesn't exist in the earlier version (so that you still have to be mindful of).

 

[gemma-the-husky]

bob

thanks for that. something else to experiment with, then, i guess.

 

[accesslearner]

In order to use a function from the applicable library you would need to reference it with the upper level application object you create. It compiles because it isn't calling anything at that point. It may not run if you don't do it correctly, which is why many times I will set the references and use EARLY binding for development but change it over to LATE binding for production. Then I need not worry about versioning problems, unless I'm using something from a later version which doesn't exist in the earlier version (so that you still have to be mindful of).

Thanks for the reply but were in the VB code should I declare these variables.

Dim objXL As Object
Dim objWB As Object



Set objXL = CreateObject("Excel.Application")

should it be inside a procedure or before the form opens. Should it be after option compare database. also for word and outlook should i just say word.application and outlook.application in the CreateObject.
I do apologize since this is a very basic question but i am a novice as far as coding goes.

Thanks

 

[boblarson]

Thanks for the reply but were in the VB code should I declare these variables.

Dim objXL As Object
Dim objWB As Object



Set objXL = CreateObject("Excel.Application")

should it be inside a procedure or before the form opens. Should it be after option compare database. also for word and outlook should i just say word.application and outlook.application in the CreateObject.
I do apologize since this is a very basic question but i am a novice as far as coding goes.

Thanks

The code goes wherever you currently have code with something like

Dim appXL As Excel.Application

etc.

Same with Word and Outlook:

Dim wdApp As Word.Application
becomes
Dim objApp As Object

(you don't need to rename the variables but I like naming them like they are going to be finally used)

Set objApp = CreateObject("Word.Application")

and like Outlook:

Dim objOutlook As Object

Set objOutlook = CreateObject("Outlook.Application")


and so on.