P.s.., Richard, I realize that the Query isn't formatted in accordance with your Query Naming Patterns.  However, our IT guy set that up for me and I've never taken the time to change it.

It's not good practice to store "dynamic" data in tables -- data that change constantly like current date and time.  To know the people's ages, all you need to store in your tables are their dates of birth.  Then you calculate their ages *somewhere else*, such as on forms or reports, where you can use Now() to get the current date and time.  Any data that is ever-changing, like date and time, shouldn't be put in a table.  That's why tables don't allow the use of Now(), Date(), or Time() as the default value of a date/time field.

Thank you, Kevin.  I wasn't aware of that at the time I setup the tables.  I will review to see what I need to correct.

Kevin's comment is correct so I am glad you are looking into that. If you need to run an event every day, you can attach a macro or VBA to the OnLoad event of your main menu form. I have an event I want to run every Friday and that is how I do it.

Thank you, Joe.  Can you define "OnLoad Event" as it pertains to this situation?

Yes, there are a lot of ways to automate something like that. First, yes, it's possible. You'll need some way to kick it off.

If you open the database yourself every day, you could put code to run it in your main menu startup form. Put a little VBA code in that form's On Load event that runs the query. You'll have to turn warnings off first, otherwise you'll get the confirmation prompt every time the update query runs.

Another option is Windows Task Scheduler. You can have Windows open the database and run whatever startup code you need on a schedule. I have a video coming out on that pretty soon - how to get Windows to open your database and do stuff automatically.

I also have a database that I have running 24/7 called Looper. Basically, its only job is to sit there, and I launch different events, backups, checking email, forum posts, and all that stuff. It just runs 24/7 doing different stuff for me, and I can launch other databases from that database.

Now, for the deeper question: what exactly is this query doing? I agree with Kevin that you generally shouldn't store dynamic values like the current date, current time, or calculated age in a table. Store the member's DateOfBirth, then calculate the age when you need it on a form, report, or query.

There are cases where saving a static value is appropriate. For example, I save monthly sales snapshots in a historical reporting table. If an old sale later gets corrected, the snapshot might not match the current live data, but that snapshot is intended as rough historical reporting, not the gospel of my sales. Temporary tables and reporting tables can have legitimate uses too. You just have to ask what this particular update is accomplishing and whether it needs to be permanently stored.

There's nothing inherently wrong with spaces in names like "Update Current Data." You just have to remember brackets around the name whenever you refer to it, like [Update Current Data]. Personally, I avoid spaces because it makes VBA and SQL less annoying to type.

And regarding Joe's suggestion, a form has several events that occur while it is opening, including On Open, On Load, and On Current. The On Load event occurs after the form has loaded, and it is often a good place to run startup tasks like this. I cover the differences here:

Form Opening Events

The current Screenshot is a copy of a Report of individuals in a group, from Oldest to Youngest.  I scrubbed the copy and delete names and other sensitive information and am only showing "Current Date", "Birth Date" and "Current Age" as of today.

I don't know if your last post has a question behind it, but Richard has a good video on Calculating Age.