Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


Developing Desktop App in Access 2010 or 2013

Posted on 2013-05-31
Medium Priority
Last Modified: 2013-06-02
I am a long time Access developer.  I started in Access 2 and have most recently been developing in Access 2003.  I know there have been several new versions since 2003 but have not had any need to upgrade.

Some background on the apps.

These are desktop apps written for clients to distribute throughout their office with the data resident on the office server.  The MDB's have been split so only the DATA MDB resides on the server.  The Proc MDB (Forms, Queries, Reports, Macros, Modules)  is resident on each machine locally.  They do not need to run on the web, in a cloud or on a portable device.

The apps we have developed in 2003 have been proven to run on newer versions of Access up thru 2010 (32 bit only).  With some modification to remove functionality that is not supported in newer version these apps also run successfully on all versions of Win 7 and even Win 8.

My clients have started to question the use of Access 2003 and expressed concerns that MS is dropping/has dropped support.  I would like to go to a more current version of Access but don't want to lose my 'framework' for project development.  I have many routines and fucntionlity techniques that I move from app to app.

I would want to preserve all of my code for standard subroutines and functions used in all of the applications.

I have read thru the 'What's new in Access 20xx' articles and come to the conclusion that up thru Access 2010 most of what I have developed will be useable and that the development environment (Forms, Queries, Reports, macros, modules, VBA code) is the same.

It seems as though 2013 is a departure from the standard and more geared to Web and Cloud based applications.  That is fine and a good step by MS but I don't want to go to a MS Access version that would make all of my developement obsolete.  As mentioend above I have many modules and lots of code that had been battle tested.  I do not want to have to re-invent and retest this.  It seems as though in 2013 the concept of forms has been changed and VBA code is no longer supported.

Based on what I have read Access 2010 seems to be as far as I want ot upgrade at this point.  I am looking for insight from EE developers that have made a similar transition and what they have uncovered in doing so.  I realize that reading the MS blurbs about the features and 'wonderfullness' of the new versions doesn't give a complete picture of the problems that will be encoutered by developers moving from version to version with hopes of retaining their framework.

An input from develpers that have made the transitions is welcome and encouraged.  What kind of problems were encoutered moving up thru the Access version.  I can read the documented features/functionality that were eliminated but what did you encounter in the way of undocumented problems and gotchas?

Thank you in advance for your input and sharing of experiences.

I realize there is no right answer to this question so I will award points based on applicable responses.
Question by:mlcktmguy
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
LVL 85

Assisted Solution

by:Scott McDaniel (Microsoft Access MVP - EE MVE )
Scott McDaniel (Microsoft Access MVP - EE MVE ) earned 500 total points
ID: 39210604
I've successfully upgraded many apps from older versions (generally 2003) to 2010. I haven't moved any to 2013 just yet so can't comment on that.

IMO, if you want to stay with the desktop paradigm you should move up to 2010. The big focus in 2013 is the move to the "cloud", and the move to web-based Access apps (which would requite a rewrite, since you can't run VBA in Access web apps).
LVL 77

Accepted Solution

peter57r earned 500 total points
ID: 39212532
As far as Desktop apps go I haven't seen any functional difference between A2010 and A2013 , although Office2013 has, in my opinion,  the ugliest UI ever devised.

Moving from 2003, I dare say you are aware that if you convert to accdb files then you will no longer have Access workgroup security available , no replication feature and ADPs disappear for good in A2013, having gradually been phased out in A2007/2010.
The most obvious change though leads to what I think is the least obvious 'gotcha'.
The most obvious change is that  ribbon replaces menu bars and that takes some getting used to.  In general custom menus from A2003 will run, but can't be edited.  Creating custom menus which include your own new menu items in A2010/A2013 can only be done using xml.  This has been a big issue, and has provided an opportunity for one company to develop what has become a de-facto add-in to provide a user friendly way of developing custom menus/ribbons.

Although your Q is about desktop apps, it is probably worth mentioning the introduction of 'Web Databases' - as Scott said above, these are quite different to desktop databases and in programming terms are macro based and have no vba.  You cannot convert a desktop database to a web database - it is a redevelopment job.
Also, a significant difference between A2010 and A2013 is that in A2010 you can develop offline and then implement to the cloud, whereas in A2013 you need the cloud for development as well - you can't develop offline.  
The backend technology is significantly different too, with A2010 using SharePoint to hold the data, and A2013 using SQL Server, albeit through a SharePoint interface.
LVL 10

Assisted Solution

by:Luke Chung
Luke Chung earned 500 total points
ID: 39212928
In addition to staying current, the reason to upgrade would be to take advantage of the ability to add new features at little to no cost. Some of the new features would have been impossible to offer in 2003 no matter how hard you coded.

I wrote about my favorite post-Access 2003 features in this paper: http://www.fmsinc.com/MicrosoftAccess/2007/Top-Features.html

Hope you find it helpful.

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.


Assisted Solution

by:Armen Stein - Microsoft Access MVP since 2006
Armen Stein - Microsoft Access MVP since 2006 earned 500 total points
ID: 39212989
To clarify Peter57r's statements even more:

Access 2013 supports desktop client applications just fine.  I know Microsoft is really touting the new web features, but these are additional to the client features, not instead of.

Yes, ADPs, ULS and a few other things have been deprecated.  But these were on the way out before 2013.

Regardless of whether you move to 2010 or 2013:  If you turned off all built in menus and didn't have your own custom menus and toolbars, then the new Ribbon interface won't affect your app too much.  But if you used them, you'll need to learn how to build your own Ribbons.   This is a learning curve but pretty well documented at this point.

At this point I'd recommend using Access 2010.  It is now a stable release with some service packs.  We do all of our Access desktop development in Access 2010.

Hope this helps,
Armen Stein
LVL 10

Expert Comment

by:Luke Chung
ID: 39212999
Access 2013 doesn't support graphs, pivot tables and charts, and ADPs, so if you have any apps that have that, stick with 2010.

Author Closing Comment

ID: 39215174
Thanks, this is exactly the kind of feedback and direction I was hoping for.  For right now I'm going to upgrade to 2010.

Featured Post

Microsoft Certification Exam 74-409

Veeam® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

AutoNumbers should increment automatically, without duplicates.  But sometimes something goes wrong, and the next AutoNumber value is a duplicate.  This article shows how to recover from this problem.
In Part II of this series, I will discuss how to identify all open instances of Excel and enumerate the workbooks, spreadsheets, and named ranges within each of those instances.
In Microsoft Access, learn different ways of passing a string value within a string argument. Also learn what a “Type Mis-match” error is about.
Have you created a query with information for a calendar? ... and then, abra-cadabra, the calendar is done?! I am going to show you how to make that happen. Visualize your data!  ... really see it To use the code to create a calendar from a q…

636 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question