AutoExec

[DJ100]

Hi, I have a multi-user split access db which is running really well. What I really want to do is run an update routine (which is already written) when the first person launches the DB in the morning - but not anyone else.

Is there an easy way to look at a flag file somewhere (which will probably be a date) say if = today do nothing else run the update and stamp the flagfile with todays date.

any help gratefully received

 

[KenHigg]

I'm thinking you're going to save this to a table and check it when the db first opens.

 

[MSAccessRookie]

Hi, I have a multi-user split access db which is running really well. What I really want to do is run an update routine (which is already written) when the first person launches the DB in the morning - but not anyone else.

Is there an easy way to look at a flag file somewhere (which will probably be a date) say if = today do nothing else run the update and stamp the flagfile with todays date.

any help gratefully received

You could create an Application Table with a Column that contains the date of the last update. When the application starts, the Macro would compare the date, and if it was today, it would exit. If it was before today it would run, and set the date to today as part of the process. I can forsee two possible (although small) issues that would have to be considered.

1. If the Macro sets the date after it has completed its task, there is a small possibility that another person could start before the Macro has completed.
2. If the Macro sets the date before it starts its task, there is the possibility that the task could fail and not be executed again on that day.

Neither of these issues should occur on any high level of frequency, so choose the one you like the best and see how it works for you.

 

[KenHigg]

You could create an Application Table with a Column that contains the date of the last update. When the application starts, the Macro would compare the date, and if it was today, it would exit. If it was before today it would run, and set the date to today as part of the process. I can forsee two possible (although small) issues that would have to be considered.

1. If the Macro sets the date after it has completed its task, there is a small possibility that another person could start before the Macro has completed.
2. If the Macro sets the date before it starts its task, there dis the possibility that the task could fail and not be executed again on that day.

Neither of these issues should occur on any high level of frequency, so choose the one you like the best and see how it works for you.

And to add a bit to this - I would call a 'startup routine' (code) with the autoexec macro that did this instead of trying to do it soley in a macro. Just my 2 cents -

 

[MSAccessRookie]

And to add a bit to this - I would call a 'startup routine' (code) with the autoexec macro that did this instead of trying to do it soley in a macro. Just my 2 cents -

As always, Ken makes a good point. having the Routine based outside the Macro gives you even more control over its actions. Let us know how it turns out.

 

[boblarson]

And Darn! I just had a thread somewhere where I went through this whole thing about this. It included a table to set the run date, code run via the AutoExec macro (using RunCode) and checking to see if the data was today or not. And, also making sure that the code also ran if just activating with the database open (if someone tried to run the macro while their database was still open from yesterday). I just can't find the thread...

 

[KenHigg]

Three heads are better than one

 

[ions]

This should be a feature of access as part of start up options.

 

[gemma-the-husky]

but note there is ALWAYS an issue with setting/clearing process flags to do stuff, I think - there must be logical proof if this!

you have to set/unset the flag at some point, and if the app crashes, or the user just closes access, the flag may not be cleared correctly.

eg do you know Sage? - when you log in, you create a user entry. now if you crash out for some reason, when you login again, it asks you if you are already logged in - sinve there is no way for the programme to know for certain whether you are logging in, in error, or whether you had a problem last time.

so what if you login, your process sets the date in your table, but the update fails. now any subsequent user just checks the date, and thinks the process ran ok, or someone else is still doing it - so it never runs. iwould always provide a manual option as a safety feature.