I have only just become aware that we should not use date as a field name. I've avoided the word "Name" for ages but didn't know about date. It goes without saying that I have used a date field name in almost all my db's! As db's are added to & fiddled with they can be quite tricky and to change a date field could be a "Pain In The B___T".

***///@@@???-- :eek:

I'm hoping what I have already done will continue to work correctly as they appear to now?

As long as you aren't using VBA or Functions to manipulate the [Date] fields, you should be ok. Be extremely careful to delimit any potential reserved word with square brackets - [Date]. You may have other field names that can also cause problems. Be warry of any simple one or two-sylable words in particular because they are potential reserved words either for SQL or VBA or both. They will be used as internal functions such as Date() and Year() or properties such as .Name and .Value and .Text. You should scan the lists of reserveds words to get a feel for what you are looking for.
A2002 Reserved words (http://support.microsoft.com/default.aspx?scid=kb;en-us;286335)
Jet 4.0 Reserved words (http://support.microsoft.com/default.aspx?scid=kb;en-us;321266)

When any language such as VB, C++, SQL analyzes a statement, it starts by taking the "word" it sees and comparying it to its list of "known words". If the compiler/interpreter/parser does not find the word in its own list, it checks any other libraries that you have defined for reference purposes (such as the DAO 3.6 library or the Word library) and finally when it exausts all its libraries, then it looks for a user-defined definition such as a column in a table or a sub or procedure name or a variable name. Surrounding your user-defined "word" with square brackets indicates to VBA and SQL at least (other languages have other rules) that the "word" is a user-defined one and so it looks at your definitions first. But if you just wrote something like
If StatusDate = Date Then, VBA would assume that you were referring to the Date() function rather than your own [Date] field.

If you have A2K or newer and your db was not converted from an earlier version, you can turn on the name auto correct options. Make a back-up db before you continue!!! Then you can open the table in design view and change the name of the Date field to ActionDate or whatever name makes sense. Then save the table. Access will propagate this name change to forms/reports/queries - but NOT to code. After you change the column name, open each object that references the column and make sure that the change was propagated. I have found some cases where the change is not propagated but not enough so I could determine the cause of the error and so predict the behaviour so be careful and be sure to test thoroughly.

PH
Thank you for your help on this matter. The lists of "reserved" words is much longer than I would have thought. It goes without saying that I'll be endeavouring to avoid them in the future, it's the past that has me concerned. It looks like there's not much we can do other than good old editing, where possible.