You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
After a long, hard effort by many people, the stars have finally aligned. The Access team is pleased to announce the release of the Access 2013 Runtime! We know lots of you are very anxious to get your hands on the Access 2013 Runtime. You can now go and download the Access 2013 Runtime from the following location:
The Access 2013 Runtime is available for download in 38 languages.
Microsoft Access 2013 provides a rich platform for developing database management solutions with easy-to-use customization tools. If no end user customization is required (including report modifications), you can choose to distribute those Access 2013 solutions so that they run without requiring a full installation of Access 2013. To do so, you must package and distribute your application with the Access 2013 Runtime.
Web-based apps for SharePoint that are built with Access 2013 do not require a runtime--only a supported web browser is required.
Is there anything that the Access 2013 runtime can do that the Access 2010 runtime can't? I appreciate there is a different look to it, but am I right in thinking that the Access 2013 desktop client experience is otherwise just a subset of the Access 2010 experience, some functionality having been removed, e.g. pivot tables, pivot charts etc?
How would one use the runtime 2013 if the Package Solution Wizard is not available in 2013? Is the PSW available in 2013? I have downloaded the runtime 2013 but seems pointless since the PSW I used with 2010 is no longer available in 2013? I would be grateful if someone could tell me how to make the PSW available in Access 2013! Runtime may make it possible to run my application on a machine that does not have Access 2013 installed but if I can't package my application what good is runtime?
This is an important question Alan has raised. I am just about to start a new project and need to know whether to use Access 2010 or 2013. I will stay with 2010 if it is a superset of 2013 (as far as the runtime is concerned)
Is it possible for you to just link to the download page and install from there. I used to get my customers to do the installation of the Access 2007 and 2010 runtimes themselves.
I think the package solution wizard has been discontinued in Access 2013. Please have a look at the 'Discontinued features and modified functionality in Access 2013' at office.microsoft.com/.../discontinued-features-and-modified-functionality-in-access-2013-HA102749226.aspx
Even I had been looking for this functionality. It is a pity it is not available any more. Option is only the recommended 'Access App' route and you may need sharepoint2013...
You are right in thinking that Access 2013 desktop client is a subset of Access 2010. From an end users perspective, the features that have been removed from the Access Runtime that they are likely to notice are no pivot tables & charts, no support for ADPs and Access 2003 Toolbars show up in the Ribbon in the Add-in tab. A complete list of features removed from Access 2013 is here
One important reason you might want to use the Access 2013 runtime over the Access 2010 runtime is because if a database is compiled in Access 2013 (MDE or ACCDE), it will not be able to run in the Access 2010 runtime. In this scenario, your clients will need the Access 2013 runtime. A database compiled in Access 2010, however, will run in the Access 2013 runtime just fine.
I think the confusion is in trying to creating a runtime version of a database. There isn’t really a runtime file format for an Access database. What you might be thinking about is creating a compiled database (converting an MDB to MDE or ACCDB to ACCDE). You can do this with the regular Access client by going to File> Save As> Advanced> Make MDE/ACCDE. These compiled file still need an Access client or Access runtime to execute. While I would recommended you compile your database before shipping it to end users, it is not a requirement for it to work with the Access runtime. The Access runtime will work with compiled or un-compiled databases.
One tip you might not be aware of is there is a real easy way to test how your database will work in the Access runtime without having to install the runtime. You can start Access with the \runtime switch or better yet, just rename your ACCDB file to an ACCDR. When you double click on the ACCDR file it will start the Access client in the runtime mode.
I found a problem with setting a trusted site settings when using the access 2013 runtime version to load a file from a network drive. I have an application that is linked to a SQL Server 2008 r2 db. The .accde file is located on the network drive (say z:\) and users run this via shortcut from their desktops. This makes for eacy updates. The application runs, but the MS Access Security Notice appears each time the file I loaded. In access 2010 runtime I could resolve this by playing with the registry entries and setting up the network as a trusted location (which is a crazy way to do this, but whatever...). I expected access 2013 runtime to work the same way. However, it seems like I can only set up local drives as trusted locations. I am adding to:
and have tried both REG_SZ and REG_EXPAND_SZ definitions for Path = Z:\ with an AllowSubFolders = 0x0000001(1)
I have also tried using the network name rather than the drive, putting the .accde in a sub folder etc, but nothing seems to work. Any ideas how to remove the trusted locations issue?
I also found another issue with runtime that may help some of you. If you are using older access dbs that were converted from say access 2003 and include some activex or other add-ons, the runtime may not load all the applicable files and you need to copy some of these over manually. I was running code that used MS Common Dialog Control 6.0 (SP6). I had to copy the comdlg32.ocx into C:\Windows\SYSWOW64 on the client PC before my code would run. There was no message on the system that alerted me to the missing .ocx, just sections of my application did not work properly and it took me a long time to figure this out. Hope this helps! Cheers.