Why are you creating a new database for each year?

The current year can be evaluated from the expression Year(Now), and the previous year is Year(Now)-1.  So you can plug that into your query's SQL expression.

Also, if you are using DateSerial() to get the whole month, does that mean you have 12 Queries that do exactly the same thing? What if you need to add an additional field to the Query? You would need to add that field to 12 separate objects in your database. Do you also add that field to your back catalog of databases for each Query for previous years. This can quickly become a maintenance nightmare.

While I completely agree with both Kevin regarding database architecture and best practices, I would assume that, as a developer student, you have already grasped these concepts by now. That said, let me explain how we can solve the specific problem under the assumption that creating a new database every year might be driven by company policy, periodic archiving, data isolation, or specific business logic.
Rather than replacing every occurrence of 2026 in the SQL text, I would iterate through the database's saved queries using DAO's QueryDefs collection and use a regular expression to target only occurrences where 2026 is the first argument of a DateSerial() call. This would leave other occurrences of 2026 elsewhere in the SQL untouched. The expression should also account for optional spaces between DateSerial, the opening parenthesis, and the year argument.
I'd back up the query definitions first and test the changes on a copy of the database before applying them to the production version.