Feedback by UserVoice

I suggest you ...

reference

the behavior of broken references could be improved. Actually a broken reference leads to strange Problems in Areas that are not directly affected by the reference

5 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    wilo shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    4 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Nick67 commented  ·   ·  Flag as inappropriate

        Mega!
        We have this fine page
        https://msdn.microsoft.com/en-us/vba/access-vba/articles/reference-isbroken-property-access
        which can list for us all the busted references in a VBA project
        Nice! Yay!!!!!!

        But if you got dumb and opened a file with an uplevel version of Office (say 2016) that had early bound references to Excel and Outlook and built code like this

        'Public Function TestFix()
        'On Error Resume Next
        'Application.References.Remove References!Excel
        'Application.References.Remove References!Outlook
        'Access.References.AddFromGuid "{00020813-0000-0000-C000-000000000046}", 1, 5
        'Access.References.AddFromGuid "{00062FFF-0000-0000-C000-000000000046}", 9, 2
        '' Call a hidden SysCmd to automatically compile/save all modules.
        'Call SysCmd(504, 16483)
        'End Function
        '
        '
        'Public Function TestKill()
        'Dim hadbroken As Boolean
        'Dim myref As Access.Reference
        'Call TestFix
        'TestKill = False
        ''For Each myref In Access.References
        '' Select Case True
        '' Case myref.Guid = "{00020813-0000-0000-C000-000000000046}"
        '' If myref.Minor <> 5 Then
        '' Access.References.Remove References("Excel")
        '' TestKill = True
        '' End If
        '' Case myref.Guid = "{00062FFF-0000-0000-C000-000000000046}"
        '' If myref.Minor <> 2 Then
        '' Access.References.Remove References("Outlook")
        '' TestKill = True
        '' End If
        '' End Select
        ''Next myref
        '
        'End Function
        '
        'Public Function testremove()
        'Access.References.Remove References("Excel")
        'Access.References.Remove References("Outlook")
        'End Function

        You get to find out really quick that IsBroken is completely USELESS becuase you can't remove these busted references.
        PERIOD.

        Booooooooooooooo!!!!!!!!!!!!!
        Hissssssssssssssssssssss!!!!!!!!!

        What good is identifying the breakage with VBA if you can't FIX the breakage with VBA?

        Instead, we have to late-bind EVERYTHING to get down-level compatibility.
        This should have been fixed long ago.

        If the dev can guess that a reference could get broken, thew dev should be able to VBA code a contingency. Right now you can't. You only get to suffer.

      • Mark Burns commented  ·   ·  Flag as inappropriate

        Let me try and elaborate, then.
        Given a .accdb with, say 7 references.
        These references occur in a specific sequence (likely the sequence in which they appear in the references dialog, as experience seems to show).
        When MS_Access tries to resolve the libraries upon open, when a reference error fails because of an invalid COM CLSID/missing .dll, the library is marked as broken, and attempts to load the remaining libraries are made with similar logic employed. This is the _first_ source of the problem, but I'll come back to that.

        The real problem occurs when a CLSID for _any_ referenced library _after_ the first broken one is attempted (and, depending upon the sequence of the libraries, even "internal" VBA functions like LEFT$() can fall victim to this). Once the search for a CLSID starts, and the search remains fruitless and the first broken reference is found, the search for that CLSID is abandoned, and an error message is thrown (even if that CLSID would be found valid had the search algorithm been able to "skip over" the invalid reference library).

        The easiest solution would seem to be to "punt" those bad reference libraries to the "end of the list" as they are initially loaded, so that all the valid references could be registered FIRST, and only then have the bad references "failed". In doing so, the original CLSID de-reference logic would work better, and only those broken references themselves would fail in use (thereby allowing "built-in VBA libraries" to function regardless of reference libraries' specified load sequence, and ending the infamous errors on Left$() being not found).

        HTH!

      • Mark Burns commented  ·   ·  Flag as inappropriate

        It is really the same problem for ALL broken references - any break in the COM references list for early binding can cause ANY code references in any subsequent (even internal VBA functions like LEFT$() & RIGHT$() to fail because some OTHER component is missing or has a significant registry issue). The COM CLSID/Name lookup kind of quits looking with no "skip over the one with a problem and keep looking in the other libraries" type of error handling.

      Feedback and Knowledge Base