Data macros are at the “ace” database engine and thus work much like store procedures in SQL server. However if you call + use VBA routines (which is legal), then you introduce a VBA dependency and that setup ONLY works from Access. So if you open a table via ODBC or any other way from FoxPro, or even .net, the Access store procedures will STILL run, but the VBA dependency will not work and does require Access. So you are free to install the database engine (formally JET, now called ACE). Installing the data engine as we done for years in the past does NOT install VBA nor does the database engine use or rely on VBA.
So data macros, and data trigger code will work from say c#. However the calling of VBA code requires Access to be installed (which installs VBA). And more important is the instant you have such triggers call VBA code is the instant you MUST ONLY update the data from Access.
So the looping, and store procedures available in ACE can even call other stored procedures as long as they are only written in the DATA macro language.
Having such table triggers call VBA code thus means that in addition to installing the database engine you ALSO would have dependency on VBA. So while you can call VBA code, such a setup ONLY works when using MS-Access as the client program.
So you have to re-write the VBA code as data macro code if you want updating to occur from c# or other external languages.
You do have “most” VBA functions, but you don’t have recordsets (you use for each).
edit:
I should also point out that since you can't call VBA when using ACE from c#, another road would be having the data macro operate on a linked table to SQL server, but data macros cannot operate on linked (external) tables. So your setup most certainly could work if the data was being updated from Access. However using FoxPro, VB, vb.net, c# etc. DOES allows and run data macro code be in these cases you cannot have the data macro code call VBA or any other kind of external code - and external code would be required to update SQL server since data macros ONLY operate on local native tables (quite much the same for SQL triggers also)