Microsoft has changed plenty of things with the 2010 interface. Some are more useful than others, but here’s a list of what’s new through the interface:
A lot of people may say that the table interface in 2010 is completely different, but this couldn’t be further from the truth. Yes, there are plenty of features to explore, but the truth of it is that Microsoft did one simple thing with the table object interface: They essentially combined the design view and datasheet view such that you now have access to all of those features on the design view screen. When you open a table in datasheet view, you’ll notice that there are two new menus on the ribbon: "fields" and "table"…
In a general sense, most of the features that were found under the design view in previous versions can now be found under the "fields" ribbon tab. This is a time saver, but not much to those that are already familiar with the interface of Access. By far, the most useful feature of this new interface is the fact that Microsoft has now implemented a kind of "AJAX" method for changing table properties. You can witness this yourself. Pick a table in of your databases, open it in datasheet view, go to the "fields" tab and click on any of the checkboxes located in the "field validation" section of the menu tab…
In earlier versions, you could not switch from design to datasheet view after changes were made unless you saved the table. This allowed the engine to update what was necessary, but now it can all be done on one screen, presumably at the drop of a hat! If any database is properly designed though, this should be irrelevant to end users, but it is certainly a time saver for developers!
The other part of the table interface now, is the fact that you can add automated actions after table events happen. For instance, if you click on the "table" tab in datasheet view, there are a couple new tabs called "after/before events". These are essentially the same thing as form events, and are officially called "data macros". The great thing about these is that the actions you specify on any given event can be triggered by manipulating the data in the table. This significantly cuts down on the need to write code behind form events, because some of the most common events found behind forms can also be found here.
I have not found these macros to be useful just yet, but there are still plenty of things you can do with them. To give an example, I’m going to use my orders table for an alternative audit trail sequence:
I’m going to ask Access to log any update changes that take place on records, so I know what my users are doing. In this small example I am going to ask for the order quantity, because in reality, all of my form fields except for the quantity are greyed out. Thus, the quantity ordered is the only field that can be updated by a user.
So under the "table" tab, I click on "after update" and I see the macro builder appear. I’m going to pick "log event" as my macro action (this will save details of a record update event to a system log table). Now, the great thing about this data macro builder is the fact that you can use field names surrounded in braces  to refer to their values. So I’m going to record the order id and quantity after every update:
And now, if I go to my system log table, I can see any changes that are made to that record, either in the table or in a form that is bound to that table:
Don’t forget too, that data macros can also call macro objects, which are the ones you see in the database window. Simply use the "runDataMacro" action and select a name from the dropdown list. This is much more useful to developers, simply because macro objects have much more flexibility in terms of execution possibilities.
This is a new feature in 2010 that allows you to look at application errors, as well as user-requested event logs (as in the above example). It is perhaps the most useful as a log for user-defined data macro errors. This table does not initially appear in new applications because it is only created once the first application error occurs. You can also view the log via the home screen in Access, as it will tell you if there are new errors that have not been viewed:
Continue to read with What's New in Microsoft Access 2010 - pt 2