I'm beginning to wonder if I'll just need to move all that update code to the front-end and be done with it. If it is local, then I can just do the usual "after update" stuff in other ways - so the "data macro" isn't adding much value - at least it seems to me. Really a bummer - because that is exactly when you need it. I did see another question asked that seemed to have the same problem - where it worked when run locally, but they had an external program trying to do this same thing- and apparently the conclusion was that it won't work. I have too much data I'd have to scrape out of the system to try to send the files. It's just frustrating to have it working - almost - but not quite. But since I know I'll have only one Admin - or certainly only one Admin at a time, it seemed OK to have the back-end reach back and link to the front-end for this purpose. I don't even really like it since the back-end is linking to a table in the front-end. Somehow, data is changing in the table without the data macro being triggered. If the back-end is the one effecting the change to the table - then it does not work - it is not triggered - even though I have seen/proven the change is indeed taking place. It even works when I run SQL to make that change - but only if that SQL is run within the front-end. When the form is open, if I change the content of this table, the form is updated - awesome. So, within the front-end - everything works beautifully. That table is nothing more than one field with one row, where I simply change the status comment. In this case then, this particular table resides in the front-end (so that the trigger/data macro will work), and the back-end (in a backward manner) reaches back to the front-end - linking to this particular table, and makes the change to that table. So, I thought I'd look into seeing if Access had something like a trigger, so when the back-end code reached a key (noteworthy) point, a message could be sent to the admin user - simply by making a change to data in a table. ![]() This is quite easy when the code is running locally - but in this case, the code is running in the back-end. In addition, I like to put status feedback up for users when processes take a while. In this case, I have a bunch of code in the back-end that updates the shared data, but I was trying to keep all users connected via the front-end, including the admin-type who will run that code. Yes - it is a split database, and normally you have the linkages from front-end to back-end tables. Why would it not work when coded more precisely to fire based on exactly how I'm changing it? (Table only has one field anyway - so it should work either way.) Is this a known limitation - that this can't work in a split database situation?Īlso, while on this same topic - it only works when I base it on the overall table changing, it will not work when I set it to fire based only on the field that I'm actually updating, which seems weird. I know the data is changing (via breakpoints etc.), but it will not fire the trigger (data macro) action. But when I run a query in a linked back-end database, that updates that same front-end table, it does not work (i.e., it will not even fire/trigger.) I can't see why it should care how it was changed, if it is basically triggered by a change. ![]() What I have right now successfully updates a control on a form when I manually change the data in one field of a front-end table, and even when I run a query that changes the data in that same front-end database. So I figured I'd look into using a trigger of some kind - hoping to make the connection that way. Ordinarily I might do this simply with an "After Update" event on the field of interest with some VBA etc., but in this case, I have a split database, where code is running in the back-end, and I'm trying to provide status updates to a user in a front-end. I'm trying to use "data macros" as a basis for performing a trigger-like action in Access (365).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |