Download Access 2010 Runtime, Database Engine Redistributable and Source Code Control

Tried installing the runtime on Windows 7 with Office 2007 already on it. Disabled my firewall and antivirus (Norton Internet Security). The installation failed with the following message: Microsoft Access Runtime 2010 encountered an error during setup.

Error 2203. An internal error has occurred. (C:\Windows\Installer\b3998.ipi -2147287035 ) Contact Microsoft Product Support Services (PSS) for assistance. For information about how to contact PSS, see C:\Users\Admin2\AppData\Local\Temp\Setup000015c8\PSS10R.CHM. That directory exists, but there is no PSS10R.CHM file.

This may well not be due to Access 2010 runtime. Yesterday I installed Sharepoint Designer 2010 RTM onto my PC and found that ADO had stopped working in my Access 2007. I then uninstalled SPD 2010, but still got the same problem with ADO. System Restore didn't work. I've now tried repairing Office 2007, but I get a similar message to the one I wrote of earlier. All in all my PC is now a bit of a mess. Joy, deep joy.

Hi Alan, Did you try re-registering the ADO library? Start | Run, and enter the command: Regsvr32 "C:\Program Files\Common Files\system\ado\Msado15.dll" Make sure to include the double quotes around the path.

Hiya Tom,

Have tried that, including unregistering first with "/u", but no joy, though both times the associated message box said it had succeeded. It was CurrentProject.Connection failing that alerted me to the problem, which uses ADO, doesn't it??? I can actually use ADO to open a .mdb file using code like the following: Dim con As ADODB.Connection

Set con = New ADODB.Connection

con.Open "Driver={Microsoft Access Driver (*.mdb)};" & _ "Dbq=c:\test\test.mdb;" & _ "Uid=admin;" & _ "Pwd=" Total Access Analyzer is also messed up, giving the message "Error -2147221164 - Class not registered, Procedure CTAA_Properties.LocalizePropertyOptions" which is similar to the one I get when I try to use CurrentProject.CurrentConnection, i.e. "Run-time error '-2147221164 (80040154)'; Class not registered" Any idea which class it might be since ADO itself seems to be OK? Alan

Tom,

Using the OleDb provider with ADO also works, i.e. in my case: "Provider=Microsoft.Jet.OLEDB.4.0;" & _ "Data Source=c:\test\test.mdb;" & _ "User Id=admin;" & _ "Password=" but still currentproject.Connection.ConnectionString fails.

The access 2010 runtime installer reports support of /quiet and /passive switches, but ignores these settings by always presenting a EULA acceptance box. Any help with passing EULA acceptance from the command line for silent installs?

Can both the x86 and x64 versions of the Access Database Engine be installed at the same time? I'm getting unclear signals as to whether x64 apps that use Access databases _require_ Office x64 or ADE x64 and _prohibit_ Office x32 from being installed.

Does anyone know if the Access 2010 runtime collides with retail installs of Access, like it has for every other version of the Access runtime? IOW, is installing the runtime still as risky as it has always been, sans some pricey and finicky add in like sagekey? For that matter, has anyone run into an alternative to sagekey, for Access 2010 or earlier editions of Access? Access 2010 is a real improvement over Access 2007, thank you Access Team.

@ Scott

Access 2010 Runtime had a different install mechanism than Access 2007 Runtime. We now use Catalyst which is the Office (2007 and 2010) installer. Hence it does not recognize the "/q" command-line option. The Access 2010 Runtime set up is already pretty light weight and consists of only 3 screens (one of which is EULA and hence important for the customers to read and agree).

In any case, here is an article on setup command-line options for Catalyst: technet.microsoft.com/.../cc178956.aspx. Also, you can use the Office Customization Tool in the Office system for configuring the installation options. @ Steve

The answer is no. The x86 and x64 versions of the Access Database Engine cannot be installed at the side by side. This is same as Office 2010. The installer won't let you install 32-bit if 64-bit Access Database Engine or Office or Access Runtime is installed (and vice versa). @ Michael You should be able to install Access 2010 and Access Runtime 2010 side by side. Did you run into any issues?

And thanks! It's a pleasure to hear that you liked Access 2010. :)

With regard to my problems with Access 2007 full version yesterday, a full re-installation of Office 2007 solved the problem, leaving me with both Access 2007 working and Sharepoint Designer 2010 RTM working OK as far as I can tell. I'm not going to try to install Access 2010 runtime on this machine though.

It seems that the Access Database Engine Redistributable 2010 actually installs the wrong version of the ACE driver on 64 bit. The documentation says: [If you are an application developer using OLEDB, set the Provider argument of the ConnectionString property to “Microsoft.ACE.OLEDB.14.0"] After installation if you check the OLEDB Providers in SQL Server 2008 the driver is listed as Microsoft.ACE.OLEDB.12.0 (12.0 not 14.0), not sure if this is a typo or not. I also get an error about " Cannot create an instance of OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)" when tyring to use openrowset... I thought the 64-bit released version was supposed to do away with Linked servers (explicilty or implicitly)....

Neha - I've not tried the Access 2010 runtime. There have been long term issues with previous Access runtimes which have never been dealt with by Microsoft, unless they finally did it for Access 2010. The complication has always been that each version of Access contends for 'ownership' of Access files. A typical manifestation of the issue might be that after a user had installed the plain Access runtime created wtih the packaging and deployment wizard, when they started an Access 2007 mdb, the runtime 2003 might try to run the file; or the other way around. For this reason sagekey created a system that relied on the Wise Installation System (a rather old installer system from Wise) to 'completley' isoloate an runtime installation from any retail Access installations. The sagekey system worked ok but is semi-expensive and each version of Access needs it's own product, and in general it is flawed and I'd say a bit fragile. It's never been clear to 'us' why for over a decade Microsoft knowingly issued Access runtime (&PWD) that created major issues with retail installs of Access. It would be excellent if they've fixed this, but I don't really expect that they have. Can you look into this issue for us? Or has anyone experimented with the runtime vs retail contention issue? Sorry if I have not made the best presentation of the issue, it's been years since I used the PDW and saw the issues it created. I do use Sagekey & runtime for Access 2003 installations.

@ Michael said: I can take a crack at this one. No, nothing really changed here. The problem here is that you're assuming incorrectly that somehow the access runtime edition is any different than the full edition of the access install. In fact the problems associated with multiple versions of Access is the same with a full edition or the runtime edition. It's the same code base and the same installer. So that compatibility runs all the way down to even having the same incompatible problems! ;-) The Access team doesn't own those installers. It is part of the overall office suite install. In other words in terms of compatibility, even the problems of installing multiple versions of Access will result in the same compatibility issues. There is not really an issue of the runtime vs. a full edition here. That runtime system is essentially the SAME code base and is based on the SAME installer. There's not some specific or different treatment to even as to where the same directory that the runtime edition is installed into (it is idential to the full version). The only real essential distinction that can be made here is that some of design services are disabled or removed in the runtime addition, but other than that it's the same thing. I'm not saying the above situation is ideal. However, the above explains that the installing routines and actual office install itself is not anything separated out to specifically ms-access runtime alone. At one time I read that there was many as 80 developers just working on the excel installer alone. Of course now all of those office parts and systems and installs are rolled into one big installing system that's maintained by a office installer team. That team has nothing to do with the Access team. I'm not trying to sugarcoat anything here, but I'm just explaining to you that the office install routines and that of installing the office system is exactly the same for the last many versions. The full edition of Access or the runtime is exactly the same part of that installing system, and there's not some special treatment or difference here. What this means is that there is a significant number shared components like the spell checker, the VBA libraries, VBA editor, the ADO and DAO stuff. And, even some of the references set up to the database engine. So, all of this installing system and these installers are built around the standard office install system and a lot of stuff needs to be installed. Thus Access is simply part of the shared office system. So, the full edition of access or the access runtime has never been treaded as any different than any other part of the office ranging from installing excel or PowerPoint or whatever. So today the office installer system is common to all the office applications, and that includes Access, and therefore that includes the runtime install. The main issue here is that the Access is not really some special edition or seperate part of the office install that gets any kind of special treatment. I wish the above it wasn't the case. The only real solution is to resort to some third party installer such as sagekey. About the only silver lining here is now that the runtime system for Access is FREE where it used to be quite expensive, then that makes the whole process of purchasing some scripts from sagekey a lot more affordable. Albert D. Kallal (Access MVP)

Edmonton, Alberta Canada

kallal@msn.com

Thanks for the clarification Albert. No, it wasn't that I had somehow assumed that the runtime used a different installer. I *would* have assumed that the Access team would care about runtime installations blowing up retail installations. The solution wouldn't have to be any more complex than the Sagekey solution. Since Access devs have been beefing about this issue for ages and ages, the Access dev team sure knows about it. Again, I would have assumed that the Access team would care about the infidelity the runtime introduces, and would have done something to fix it by now. But that's how it goes with Access. The collisions of runtime and retail versions of Access is a little more nefarious than retail #1 bumping retail #2. With retail #2 installed side by side with retail #1, at least the end user/IT dept has a chance of knowing there might be an issue and that they have installed two editions of Access. With retail and runtime, the end user does not necessarily know that they're installing another copy of Access, same version or different than the retail copy they have. And it's very likely that the developer doesn't know what versions of retail (or runtime) Access might exist on the various user machines. The PDW runtime setup introduces a complete wildcard to the Access ecosystem. Even with Sagekey's products, each version is only good for one Access version in combination with the known editions of Access at the time it was built. If I distribute an Access 2007 runtime with sagekey, and Access 2010 retail is installed later on any of the same pcs that my product is, all bets are off. Will Access 2010 retail interfere with my Access 2007 runtime? Or will Access 2012 retail? I've not been vexed by that issue in particular, but only because I try to avoid the runtime as much as possible. Anyways Albert you already know all that, I just wanted to articulate the issues. At least I know the same silly issue dogs the new runtime.

I installed and tried the 2010 runtime with one of my applications. Works, nothing out of ordinary as far as I was able to see.

BUT there is a major problem with speed, the application is running fast, until there is some manipulation of controls on the form (I have a calendar form, and barchart for clockin/out app by using the rectangles, and resizing/placing them based on data).

It is at least 4x slower then it was on 2003. This is interesting at least, why would this be? I measured with using timer() and 2003 runtime did it in 0.6sec, 2010 in 2.5sec. The same on 2007 is only marginally slower then 2003, maybe a factor of 1.6 or so. A partial screenshot of the form as it looks is here www.blackstudio.com/accessform.jpg , just for a feeling what it is about.