In VBA I doubt if the difference in term has much meaning. I tend to use the term ‘Overloading’ because it implies the same name but in different context. In other languages, such as C++, it has a more defined meaning but in VBA it can be defined as ‘Scope of Context’.
Example:_
The new MkDir Function overloads the old MkDir Statement in as much as the new MkDir Function takes priority over the old MkDir Statement. But the new MkDir Function does not overload the VBA.MkDir Statement because the VBA qualifier forces the ‘Scope of Context’ which the compiler will use.
The reason that I started this thread was to make sure that the internal MkDir Statement can’t be called from within a Query. If an Access Function, such as Now(), is overloaded it causes the Now() Function to fail in Queries. I did this once in VBA to overload the Now() Function to get it to return server time. The reason for that was, for instance, an audit trail often uses Now() to timestamp a record. But Now() uses front end time and not all front ends would necessarily be time synchronized. The problem was that the overloading worked in VBA but not if Now() was used directly in a Query. It’s fine if the Query is built in VBA because the Now() Function then becomes the VBA.Now(). May say to readers at this stage, I’m not looking or interested in workarounds for that either.
But to answer your direct question about overloading verses overriding; I’m not too fussed with what it’s called provided it works properly within the requirements. Perhaps the correct term would be ‘VBA Overloading with Scope of Context’ but who wants to write that all the time?
If you’re interested, another candidate for overloading might be the Kill Statement. Currently it won’t Kill the type of file Dave was talking about but I’ll bet there’s an API call that will.