VBA
Failure with missing References.
Why does VBA fail with broken references that have nothing to do with the fault debug stop line in code? ( like Left$ or Date ). VBA looks up the function you are calling and walks through references to resolve the member. It does this because is is not clearly 'disambiguated'.

eg: Left$(MyStr,2) .....v..... VBA.Left$(MyStr,2).

OK, but why doesn't the system search the references in order...isn't that what the up / down in the references dialog buttons are for? Yes...and no. The position buttons and position of the references only applies to non 'Built in' libraries. In fact they are disabled when you get to the Access object library. Basically the application first searches in the current module, then in the other modules in the project and then finally in reference order, prior to getting to VBA. You can test this by writing a function with the same name as a VBA function.

As you can see, the above function is not the VBA Left function. It is in fact a test function supplied by a ActiveX dll I wrote to demonstrate the point. Notice it was suggested by intellisense prior to the VBA version. If I wrote yet another Left function in a std module, then it would be the first cab off the rank. So now that the code has been decompiled by the broken reference, it once again rats through the libraries trying to resolve things. Unfortunately, whilst going through the referenced libraries it hits the missing one and splat.Michael Kaplan mentions these semi compiled states of VBA on his www.trigeminal.com site.

Dim a As String
a = "Hello" & Space(12)
End Sub

Function Space(var)
Space = " World"
End Function

The result here will be that the VBA Space function is not called, The Access module code is called instead and 'a' will equal "Hello World". This will still apply if the new function is written in a std module or another Global namespace OLE library dll you reference. The VBA function is last on the list. So your code will hit a broken reference long before it reaches VBA.

An area which commonly crops up in the news groups lately is the 'Type Mismatch' error number 13 when dealing with databases / recordset members. This is because Access use the DAO library interface into Jet whilst Access 200 uses ADO. Both support members with the same names but the members are distinctly different types. A DAO recordset is not the same type' as an ADO recordset. Because libraries can have members with the same name as other libraries, and you can load these libraries simultaneously you need to 'disambiguate' (a Microsoft term) the member.

Dim rst As DAO.Recordset
Dim rst As ADO.Recordset
Dim rst as Woofler.Recordset.

Thus if all the code in your project was fully qualified to the library then *only* the code dealing with the missing library reference would fail. This is the Key to my application. All code that must run prior to repaired references is fully qualified and so will run to completion and restore the missing libraries / references.
This concept is not proverbial to veterans let alone the novice - hence the complaining about DLL Hell for so many years.
Further information on References is available from References 101