When you use Late Binding (and you've got the general idea), you can then remove that reference from your database. Late Binding allows VBA to use whatever version of the library is currently installed on the machine. So if you move your database from a machine with Excel 10.0 to a machine with Excel 12.0, Late Binding will use the 12.0 library to make your calls.
Once you resolve your reference errors, the issues with things like Left and Mid will go away.
You should also compile you application before shipping to insure that you've fixed everything. From the VBA editor window, click Debug - Compile and fix any errors that show up.
In addition, you must be VERY careful when installing the Access Runtime on a PC with an existing full version of Access. You can really muck things up if you don't handle this properly. Sagekey software (
www.sagekey.com) is a firm that came into existence specifically to handle this sort of thing. When you fire up 2007, it "registers" itself on the machine as the default application to handle all .mdb/.mde/.accde/.accdb files ... this is all fine and well when dealing with YOUR app, but when users then go to another Access application and doubleclick it to run, then the 2007 runtime opens ... not exactly what your users expect to see! The fix is to ALWAYS launch ALL applications from a shortcut, but of course that is a difficult task (at best) for machines with existing Access apps. The Sagekey scripts work by launching your application using a separate executable that (a) stores all the current info about the currently registered Access version, (b) registers 2007 on the machine, (c) fires up your app and then, when you close it (d) de-registers your app and re-registers the previously registered version. IMO, it's the only way to deploy the Access runtime if you want to avoid a lot of very nasty support calls.