Using Access 2010

Last Updated Sunday April 17, 2011

home

 

This page is intended to report differences found in Access 2010 compared with earlier versions, plus other information that may be of use.

 

The Faculty's labs will be using Office (and thus Access) 2010 from September/October 2010.

 

This version of Access is not such a radical change as Access 2007 was over previous versions. It still uses the Access 2007 file format as the default format, and the interface is still based on the ribbon (though some things have changed and are not in the same places as before).

 

What's New

Items no longer supported

   Calendar Control

   Data Access Pages

   Further Links

Problems

  Run-time error when sending emails

   Styles are out and Themes are in

   Converting Macros to Code

   Error when converting .accdb to .mdb

   Possible error when using File Picker

Some other Links

My Access 2007 page

My FAQ page

 

 

What's New

 

Searching Access Help with "What's New" gives the following links (and several others about specific topics):

  1. http://technet.microsoft.com/en-us/library/cc179181.aspx Help says that this is really for IT and database admin info - but I think it's also of use to developers. Detailed discussion of various changes.

  2. http://office.microsoft.com/en-gb/access/access-2010-features-and-benefits-HA101809011.aspx Help says this link is for features, but it’s looks to me like just a very general overview/advertisement.

 

Some new things that might be of interest:

 

Some items that are no longer supported (will give error message):

  1. Calendar Control. The article at the first "what's new" link above suggests using the date picker instead; this appears to the side of date fields on tables and date format text boxes on forms. See also the document linked here for an explanation of the error message Missing or broken reference to the file 'MSCAL.OCX'.

  2. Data Access Pages (they worked in Access 2007 but now won't work at all). The new web service enhancements in Access 2010 are intended to fill the gap.

  3. See also the document attached here for a list of discontinued features.

  4. And this link: http://blogs.msdn.com/b/access/archive/2010/01/09/access-2010-deprecated-features-and-components.aspx

 

Problems:

  1. Run-time error when sending emails. A previously-working (in Access 2000-2003 and 2007, Access 2000 file format) database that used DoCmd.SendObject to send emails crashed in Access 2010. See VBA FAQ 28.

  2. Styles are out and Themes are in. When creating a new form or a new report, previous versions of Access would give you a choice of Styles from which to select. This was useful for legacy databases so that you could create forms in, say, Access 2003 style, and use a common style for reports.
    If you have a database with an Access 2000-2003 file format (i.e. a .mdb database) then Access 2010 no longer gives you this option - you are presented with a new form or report in Access 2010 layout, whether you like it or not!
    It looks like Themes now replace Styles, but these only appear to be enabled (on the Form/Report Design Tools on the Ribbon) if you are using an Access 2007 format (.accdb file extension) database.
    I have not found this change mentioned in any Microsoft 2010 items that I have looked at, nor do I have any idea why the change was made. The idea of Themes looks a useful one, but removing the previous option of styles does not seem particularly helpful if you are maintaining a legacy database and wish, or need, to keep the pre-2007 file format.
    I found a couple of websites that look to be useful in explaining how to use Themes. These are:
    http://blogs.msdn.com/b/access/archive/2009/09/25/access-2010-custom-themes.aspx and
    http://answers.oreilly.com/topic/1848-how-to-create-forms-in-microsoft-access-2010/ .
    This site http://allenbrowne.com/ser-43.html could also be useful for getting common styles for forms and reports (I've not tried it out, but Allen Browne http://allenbrowne.com/index.html has a very good reputation).

  3. Converting macros to code. Starting with Access 2007, the form and report wizards now generate macros by default for controls rather than VBA code. See my Access 2007 page, then the link for 'Wizard Code'. In Access 2010 the option for converting a form's macros to VBA is now on the Form Design Tools ribbon (and presumably similarly for reports). However, this option doesn't work in Access 2010! If you try to convert the macros you'll get an error message: "there was a problem converting the macro". This looks to be a bug in Access 2010 - see http://social.answers.microsoft.com/Forums/en-US/addbuz/thread/edebfb3b-2ab2-4697-872b-d52b9bd0994a : "this behavior has been filed as a bug and is being looked at by our development team", July 2010.
    So - How to get round this problem? Some ways could be:
    (a) Convert the .accdb database to the previous (.mdb) format    . See Save a copy of an .accdb file in the .mdb file format in Access 2010 Help. Then wizards will create VBA code. However, if you are using new Access 2007/2010 features you may not be able to convert to the earlier format. Even if you don't think you are using anything new, you may be doing so without realising. The conversion will then fail with a message saying that "This form or report contains changes that are incompatible with the current database format". On my machine Access then 'encountered a problem' and had to close. I deleted all the form buttons and replaced them with non-wizard buttons and the conversion then went OK (I subsequently realised that simply removing the '[embedded macro]' entry from the relevant button event on the property sheet does the same thing and is far simpler!). There may be other controls that you also have to delete/recreate; I have also hit this problem with an image control. This method means you can't use any new 2007/2010 features, of course, and that you now need to write the button code yourself (see next option (b) below) or recreate the buttons in the .mdb file this time with wizards to generate the code.
    March 2011 It could be that form/report layouts are the cause of the 'incompatible' error mentioned above. My thanks to Dan Yedinak of Oregon, USA, for drawing my attention to the discussion at http://www.utteraccess.com/forum/combo-box-trouble-t1949853.html. I tried this out with the database I was using before, found a form where the layout was 'stacked' (the one where I hit the above-mentioned problem with the image control), removed the stacking and the conversion to .mdb was then fine. This 'stacking' was first introduced with Access 2007 and appears to have been dropped from Access 2010 (see my Access 2007 page and the link for 'Forms and Reports') - perhaps that's the reason for the above-mentioned bug. The database I was using was originally created in Access 2007, and the Faculty installed Access 2010 in the labs for 2010/2011.
    (b) Code everything yourself from scratch - or don't use wizards that create macros (but not sure how you tell which do and which don't...). This method requires more coding, so you need to know what you're doing. Look at an old database to see the format of wizard code for buttons, then simply copy the format for each button you want. Or create a test .mdb database and use that to generate wizard code which you then copy/paste to your .accdb database behind a non-wizard control. March 2011 See VBA Wizard Code database on my Example Databases Page.
    (d) Resign yourself to the fact that you won't be able to convert the macros and just put up with it. But you should still be able to code the bits that you want elsewhere (to get at a code window, open the form/report in design view and click on the 'code' icon - this will create a new code module for the form/report if one didn't exist before, or open the existing one.. You just won't be able to add your own code to wizard-generated code (which is a pity as this can often be useful).

  4. Possible error when using File Picker
    The maximum length allowed for the .Title property of the File Picker seems to be 127 bytes (worked out by trial and error - Access Help is far from helpful here). This restriction did not seem to apply with Access 2007 (?).

 

Some other links: