Data Macro triggers/fires only under certain circumstances

[jdraw]

I'm not following the logic, but I do see you have a macro error

USysApplicationLog USysApplicationLog

ID	SourceObject	Data Macro Instance ID	Error Number	Category	Object Type	Description	Context	Created
1​	tabFEMessages.AfterUpdate	{D08D52BF-0AEB-440F-BB89-2149FF6D4440}	-8084​	Execution	Macro		SetLocalVar varStatus, UpdateStatus([StatusMessage])	10-Mar-21 9:11:46 AM​

 

[Papa_Bear1]

Interesting... After looking into that - it seems those errors were there only due to issues while I was setting it up. It now seems to work without generating any new errors...

I ended up adding a command in the back-end code that runs a query in the front-end that modifies that table - thus - the front-end gets tricked into thinking it is making the change, when it was actually already changed (by the back-end) - but since the query exists in the front-end, this then triggers the Data Macro. Kind of weird - but it works.
Thanks for all the ideas/help/responses!

 

[theDBguy]

Interesting... I'll dig into that.
I ended up adding a command in the back-end code that runs a query in the front-end that modifies that table - thus - the front-end gets tricked into thinking it is making the change, when it was actually already changed (by the back-end) - but since the query exists in the front-end, this then triggers the Data Macro. Kind of weird - but it works.
Thanks for all the ideas/help/responses!

Hi. Glad to hear you got it sorted out. Just curious though, how is this new command in the BE gets triggered?

 

[Papa_Bear1]

Hi. Glad to hear you got it sorted out. Just curious though, how is this new command in the BE gets triggered?

When a particular user type (Admin type) is using the front-end, and they click the 'Update' button - this means they want the back-end to process new input files. So, in the front-end, I use code that lets you execute code in a separate access file - as such:

dim appAccess As New Access.Application

appAccess.OpenCurrentDatabase strPathToBackEnd
appAccess.Run "CodeToRun"

Where "CodeToRun" is whatever routine you want to execute.

I've learned since then that you need to be careful whether you really want to open a new instance (using the above "New Access.Application" or whether you want to access an Access file that is already open - in which case you'd dimension the appAccess as an "Object" and then use a command like set appAccess = GetObject(strPathToDatabase)

It took a while for me to iron out the details of "GetObject" as it has two optional inputs, and use of only the 2nd seems really weird to me - as you are telling the system to establish connection to an open Access file - in which case you'd NOT be providing the path - I find that to be a very strange way to go about it. Luckily - you can do what I've shown above - which is only supply the path - and it allows you to connect to an already-open Access database, and perform a query with something like: appAccess.DoCmd.OpenQuery "qryBlahBlah"

Hopefully that answers what you were asking...

 

[theDBguy]

Hopefully that answers what you were asking...

Not really, but it's okay. You don't have to explain everything, if you don't want to. As long as you got it working now, that's all that matters. What I am still confused about is just this part:

When a particular user type (Admin type) is using the front-end, and they click the 'Update' button...

So, if the admin user is already using the FE, then why is there a need to execute some code in the same FE from the BE? Why couldn't the FE execute that same code from within itself? Again, just curious...

 

[jdraw]

I have the same curiosity as theDBGuy. If the Admin user is identifiable, and in the FE, seems some prudent use of Is Visible and Is Enabled could be modified when the"triggering event" is encountered, and the appropriate code executed. It would be unseen to all but the specific Admin user.

 

[Papa_Bear1]

I have the same curiosity as theDBGuy. If the Admin user is identifiable, and in the FE, seems some prudent use of Is Visible and Is Enabled could be modified when the"triggering event" is encountered, and the appropriate code executed. It would be unseen to all but the specific Admin user.

Hmmmm - I guess I'm not communicating well - sorry 'bout that...

I have input data files that get imported and processed in the back-end - and it made sense to me for all of that import and processing code to exist within the back-end database. Since all of the back-end tables could be linked and accessible from the front-end, it is true that this processing could occur in the front-end. But, it just felt like back-end processing should occur in the back-end, and front-end processing in the front-end. Therefore, I wanted a user in the front-end to be able to simply launch that code in the back-end - and that actually worked quite easily. The only real challenge was providing dynamic feedback to the Admin user of progress during that import processing.

 

[Isaac]

I think you're really trying to reinvent a wheel that has worked well for 10's of 1000's of Access developers: Table data goes in the back end, everything else goes in the front end, with possible (and not very common) exception of using a data macro (in the back end).

 

[Papa_Bear1]

I think you're really trying to reinvent a wheel that has worked well for 10's of 1000's of Access developers: Table data goes in the back end, everything else goes in the front end, with possible (and not very common) exception of using a data macro (in the back end).

Point well taken!