One thing you can surely and easily refactor with exprerssíons rather than replacing the current with the next year number. Beause both SQL FROM clasue and the USE command can be used with macro substitution or name expression.
For example
claerly only works this year and
only next year but
Code:
USE ("Sales_"+STR(Year(Date()),4))
Just don't get the idea to remove the outmost brackets, this is called name expression and while
Code:
? "Sales_"+STR(Year(Date()),4))
also outputs the same string as
Code:
? ("Sales_"+STR(Year(Date()),4))
Within the USE command the outer brackets make clear that the name (of the table/file to open) is an expression, and thus can be an expression involving functions like YEAR(), too. You just need to ensure the whole expression results in the name you need.
So finally replace
with
Code:
USE ("Sales_"+STR(Year(Date()),4))
And you never need to replace it again.
Programming that way you never need to touch parts of the code again.
If you need to extend CASE statements by a new year and very specific code for that, this can't be generalizued, but that's normal application maintenance, isn't it? Anytime you have hardcoded a year that just needs to be replaced by the next number, that's just bad progreamming style, no matter in what programming language. You also don't need another programming language to have a feature like YEAR or incrmenting a number. If you need previous and next year -1 and +1 are included in the VFP language, too.
So the yearly adaptions to the next year are reduced to the actually non-automatibale places. Not doing that is neither good thinking of the original programming nor of the adaption procedure you do each year.
Chriss