I've been developing in Access for over 10 years and I've never used any of those de facto variable naming conventions like Reddick, Leszynski, etc. I was introduced to them very early on, but didn't really fancy using them. To me, they add excessive nomenclatures that add a lot of "noise" to the code. So I went on my own way from then.
The only naming scheme I would consider carefully is the naming of table field names, but that really belongs under database design, not variable naming. My scheme here is what most people would use: no reserved words, no spaces, avoid duplicate names even among different tables, etc.
Especially important to me is distinctive field names. E.g. A table of billing addresses and a table of shipping addresses should have DIFFERENT field names from one another, even though both tables have same type of data: street address, city, state, etc. To me, same "type" doesn't mean the same. I use identical field names only when two fields are TRULY the same. E.g. CustBillTo table has CustID, CustBillToName, CustBillToStreetAddr, etc., and CustShipTo table has CustID, CustShipToID, CustShipToName, CustShipToStreetAddr, etc. In this case, the CustID field is TRULY the same in purpose and content in both tables, so I would name them identically.
But most of the times, distinctive field names are preferred, otherwise it could mean big trouble. For instance, if you join the CustBillTo and CustShipTo tables in a query, and if both tables named its address fields the same way, i.e. StreetAddress, City, State, etc., you would have conflicts of column names in the query. And you end up having to rename the columns in your SQL anyway. E.g. SELECT CustShipTo.StreetAddress as CustShipToStreetAddr, etc. So the naming of table fields is paramount.
But in naming other things, such as forms, queries, modules, tables, VBA variables, etc., my "convention" is simply anything goes. Anything that is descriptive enough and understandable enough. Can have spaces. Can use plain English. Can be long names. Can have special characters like colons and dashes. Can be all uppercase, all lower case, or capitalized. Whatever convention there is is loose: a form's name has the word "form" somewhere in it; a command button's name has "btn" as its suffix, etc. E.g. "Customer subform", "CUSTOMER MAIN FORM", "Query: active customers". More important for me is that I am CONSISTENT in how I name them, and I think that is true in all naming schemes. I put the most restriction on procedure names, such as no spaces nor special characters, but that's only because VBA restricts them.
I know I'm an abject minority, and almost all books I've read on VBA always mention the need of naming conventions, especially the de facto ones. But the other day, I was reading "Beginning ASP.NET 4.5 in C# and VB" by Imaar Spaanjaars and to my surprise and amusement, the author not only doesn't really endorse using naming conventions, but also writes what seems like a knock to such a practice:
Page 202:
PRACTICAL TIPS ON PROGRAMMING
The following list presents some practical tips on programming: Always give your variables meaningful names. For simple loop counters you can use i, although loopCount probably describes the purpose of the variable much better. Don’t prefix variables with the word var. All variables are variables, so adding var only adds noise to your code. Consider useful names such as _firstName and _categoryId as opposed to strFName, varFirstName, or catI for private fields, and names like FirstName and Person for public properties and classes, respectively.