Question

I’ve heard on the grapevine that the forthcoming Access2010 has a Data Macros feature which will for the first time add trigger-like functionality to Access data engine tables. Does anybody have an further details on this? For example, can they created in code (ACEDAO, SQL DDL, etc)? Does the Data Macro run if the data is modified from outside of the Access user interface e.g. via ODBC, OLE DB, etc?

Answer 1

Ok, a bit more information.

Does the Data Macro run if the data is modified from outside of the Access user interface e.g. via ODBC, OLE DB, etc?

Yes it does.

These true triggers are at the data engine level. So, using ado, dao or even editing the tables in table view in ms-access means the triggers will fire. These triggers would also include the scenario where you don’t even have ms-access installed on your computer.

You will of course need JET installed (for the remainder of this article I will use the term ACE). Remember it was only in access 2007 that the access team received ownership of JET. They are now free to enhance this engine for their needs. We started to see some changes to ACE in 2007 and now we will see a LOT more changes for 2010. Some of these features are still NDA for me…but I will spill as much as I can here.

For example, can they created in code (ACEDAO, SQL DDL, etc)?

In code, perahps, but not with SQL ddl. The triggers are not sql commands. Keep in mind that for Oracle, or Sql server or MOST systems in the marketplace they all tend to have their OWN custom language for their triggers anyway.

In the new ACE you thus will write what is called a data macro. You use the macro editor in ms-access. These are old fashioned access macros, but the editor has been completely re-done. The new macros also have subroutines, looping, if then else blocks and a type of recordset. Remember, we received the ability to create temp variables in 2007 macros. In 2010 this is extended to also include local variables and above new features.

The syntax for existing macro commands is the same as previous versions. However, we have a new slick IDE along with all those above cool commands added. We now thus have two types of macros. UI macros (regular as before) and now the new so called data macros. It would not make sense for a table level macro to be able to display error messages to the screen. So any error logged goes into a table. There also a few new logging commands that let you write your own custom errors to that table . A brilliant and simple design here. Here what that error log table looks like:

_{(source: kallal.ca)}

In a world of huge IDE’s, massive frame works and horrifying huge libraries of code requited to update a simple row in a table, I can say that data macros are most refreshing feature. They feel much like how the original dbaseII works. They are very simple, but deadly power full because they run at the table level.

For example, here is a data macro that will maintain inventorying totals a table. In this example I’m going to assume that master inventory records exist. And then we have an order details table. If a user edits any value in the orders table, we want the master table to automatic update the inventory levels.

So we have:
I have two tables

tblFruits:    main data fruit inventory table
id         (autonumber)
Fruit text
OnHand    (number value of fruit in inventory)

tblFruitsOrder
id       (autonumber)
Fruit_id (FK to tblFruts.ID)
QtyOrder (number of fruit to order)

This is simple test

So, we going to have a trigger in the tblFruitsOrder that will update
+ maintain inventory levels in tblFruits when the QtyOrder field is
edited or modified.

Here is what the macro looks like:

_{(source: kallal.ca)}

Note how very simple the above is. Note that in the IDE if you click on a section of the code, then you get the old style macro type editing in which you can enter the values for the command (this is similar to pre 2010, but now the parameters and editing occurs in the code, not a panel that appears on the bottom of the screen in previous versions).

Here is another screen shot in which I playing with the ability to do a loop and call a subroutine.

_{(source: kallal.ca)}

In the above we can use msgboxs etc. because this is not a table level macro. So the commands available are automatically restricted for you when you writing a table level macro as opposed to a regular macro. The terminology we adopted to distinguish the two types of macros are UI macros and data macros.

The above is about all I can speak about in pubic. However there is few more REALLY neat-o features about these macros that I simply can not yet talk about in public as I am still under NDA on those features. But there is more cool surprises to come here.

Here is a screen shot of the types of table triggers we have:

_{(source: kallal.ca)}