Welcome to SPN

Register and Join the most happening forum of Sikh community & intellectuals from around the world.

Sign Up Now!

Events in subforms don't work with Japanese Access - Can't find missing DLL

Discussion in 'Information Technology' started by Rainer, Jul 28, 2006.

  1. Rainer

    Rainer
    Expand Collapse
    Guest

    Hi,

    We have an MS Access application that works fine on US and European
    Access installations but not on Japanese installations. Simple forms
    work fine, but forms that contain subforms with event programming give
    errors for each event. Our Japanese customer translated one of the
    error message as follows:

    When Event, the formula that I appointed in a property, at the time of
    resize, an error occurred:
    When SafetyCaseDB communicated with an OLE server or ActiveX control,
    an error occurred.

    We can reproduce it on multiple japanese installations. We checked all
    references on a Japanese installation and they are fine. We can
    recompile the program without compile time error. We gave every
    subroutine / function an explicit reference like VBA.Left. Still the
    help text to the error message leads to the MS Knowledgebase, entry
    283806, which says that a DLL is missing.

    To compile successfully the application requires references to the
    following DLLs / OCXs:

    MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
    MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
    MSCOMCTL.OCX
    FM20.DLL
    vbscript.dll\3

    Thank you all for the help,

    Rainer
     
  2. Loading...

    Similar Threads Forum Date
    United Sikhs UNITED SIKHS Launches Olympics Langgar Pre-Events Sikh Organisations Jun 11, 2012
    United Sikhs Human Rights Messages Transcend the Physical Boundaries of the Places & Events They Depict in Films Sikh Organisations Sep 1, 2011
    SALDEF Outreach Events Empower Sikhs of Atlanta Sikh Organisations Aug 20, 2011
    Ashamed to be Indian: After Recent Events in Uttar Pradesh Hard Talk Jul 20, 2011
    Sikh community promotes awareness about organ donation at Diwali events Community Out-Reach Nov 2, 2010

  3. Douglas J. Steele

    Douglas J. Steele
    Expand Collapse
    Guest

    Do you really need all those references?

    Consider removing the references to Word, Excel and the VBScript library,
    and using Late Binding instead.

    Consider removing the reference to MSCOMCTL.OCX and using API calls instead
    (see http://www.mvps.org/access/api/api0001.htm at "The Access Web" if
    you've only got that reference for the standard Windows File Open/File Save
    dialog)

    Access doesn't usually work correctly with FM20.DLL anyhow: why have you got
    that reference?

    The general rule is to "starve" your references: only have the bare minimum
    as much as possible.

    --
    Doug Steele, Microsoft Access MVP
    http://I.Am/DougSteele
    (no private e-mails, please)


    "Rainer" <Rainer.Faller@exida.com> wrote in message
    news:1151910503.893423.21310@p79g2000cwp.googlegroups.com...
    > Hi,
    >
    > We have an MS Access application that works fine on US and European
    > Access installations but not on Japanese installations. Simple forms
    > work fine, but forms that contain subforms with event programming give
    > errors for each event. Our Japanese customer translated one of the
    > error message as follows:
    >
    > When Event, the formula that I appointed in a property, at the time of
    > resize, an error occurred:
    > When SafetyCaseDB communicated with an OLE server or ActiveX control,
    > an error occurred.
    >
    > We can reproduce it on multiple japanese installations. We checked all
    > references on a Japanese installation and they are fine. We can
    > recompile the program without compile time error. We gave every
    > subroutine / function an explicit reference like VBA.Left. Still the
    > help text to the error message leads to the MS Knowledgebase, entry
    > 283806, which says that a DLL is missing.
    >
    > To compile successfully the application requires references to the
    > following DLLs / OCXs:
    >
    > MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
    > MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
    > MSCOMCTL.OCX
    > FM20.DLL
    > vbscript.dll\3
    >
    > Thank you all for the help,
    >
    > Rainer
    >
     
  4. Rainer

    Rainer
    Expand Collapse
    Guest

    Doug,

    thank you for your suggestions.

    My major concern is FM20.DLL. We have no clue why we have it. The
    application developed over years. Access doesn't allow us to remove the
    reference ('in use'). Any hint how to get rid of it?

    Concerning MSCOMCTL.OCX: We need it, as we make extensive use of
    TreeViews all over the program.

    The other references, we can replace by late binding. But wouldn't we
    miss the syntax check by the VBA p-code compiler?

    Thanks, Rainer

    Douglas J. Steele schrieb:

    > Do you really need all those references?
    >
    > Consider removing the references to Word, Excel and the VBScript library,
    > and using Late Binding instead.
    >
    > Consider removing the reference to MSCOMCTL.OCX and using API calls instead
    > (see http://www.mvps.org/access/api/api0001.htm at "The Access Web" if
    > you've only got that reference for the standard Windows File Open/File Save
    > dialog)
    >
    > Access doesn't usually work correctly with FM20.DLL anyhow: why have you got
    > that reference?
    >
    > The general rule is to "starve" your references: only have the bare minimum
    > as much as possible.
    >
    > --
    > Doug Steele, Microsoft Access MVP
    > http://I.Am/DougSteele
    > (no private e-mails, please)
    >
    >
    > "Rainer" <Rainer.Faller@exida.com> wrote in message
    > news:1151910503.893423.21310@p79g2000cwp.googlegroups.com...
    > > Hi,
    > >
    > > We have an MS Access application that works fine on US and European
    > > Access installations but not on Japanese installations. Simple forms
    > > work fine, but forms that contain subforms with event programming give
    > > errors for each event. Our Japanese customer translated one of the
    > > error message as follows:
    > >
    > > When Event, the formula that I appointed in a property, at the time of
    > > resize, an error occurred:
    > > When SafetyCaseDB communicated with an OLE server or ActiveX control,
    > > an error occurred.
    > >
    > > We can reproduce it on multiple japanese installations. We checked all
    > > references on a Japanese installation and they are fine. We can
    > > recompile the program without compile time error. We gave every
    > > subroutine / function an explicit reference like VBA.Left. Still the
    > > help text to the error message leads to the MS Knowledgebase, entry
    > > 283806, which says that a DLL is missing.
    > >
    > > To compile successfully the application requires references to the
    > > following DLLs / OCXs:
    > >
    > > MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
    > > MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
    > > MSCOMCTL.OCX
    > > FM20.DLL
    > > vbscript.dll\3
    > >
    > > Thank you all for the help,
    > >
    > > Rainer
    > >
     
  5. Douglas J. Steele

    Douglas J. Steele
    Expand Collapse
    Guest

    I'm very surprised that you can't remove the FM20.DLL. You might try
    creating a new database and importing all of the objects from your existing
    database into the new one (the references won't be imported: if you don't
    have a required reference, you'll know when you try to compile the
    application)

    MSCOMCTL.OCX: yes, unfortunately if you're using TreeViews or ListViews, you
    have no choice but to include the control (sorry, I misread, and thought you
    were using MSCOMDLG.OCX)

    Once your application is working, you really don't need the syntax checking
    that early binding provides. It's typical to add the reference, develop the
    application, then remove the reference before distributing the application.
    If your code uses any of the intrinsic constants that come from the
    reference (xlRight, wdPromptToSaveChanges and so on), you either have to
    define the constants as Public in a module in your application, or replace
    them with the actual value (my vote is the former).

    --
    Doug Steele, Microsoft Access MVP
    http://I.Am/DougSteele
    (no private e-mails, please)


    "Rainer" <Rainer.Faller@exida.com> wrote in message
    news:1151946155.494005.183450@75g2000cwc.googlegroups.com...
    > Doug,
    >
    > thank you for your suggestions.
    >
    > My major concern is FM20.DLL. We have no clue why we have it. The
    > application developed over years. Access doesn't allow us to remove the
    > reference ('in use'). Any hint how to get rid of it?
    >
    > Concerning MSCOMCTL.OCX: We need it, as we make extensive use of
    > TreeViews all over the program.
    >
    > The other references, we can replace by late binding. But wouldn't we
    > miss the syntax check by the VBA p-code compiler?
    >
    > Thanks, Rainer
    >
    > Douglas J. Steele schrieb:
    >
    >> Do you really need all those references?
    >>
    >> Consider removing the references to Word, Excel and the VBScript library,
    >> and using Late Binding instead.
    >>
    >> Consider removing the reference to MSCOMCTL.OCX and using API calls
    >> instead
    >> (see http://www.mvps.org/access/api/api0001.htm at "The Access Web" if
    >> you've only got that reference for the standard Windows File Open/File
    >> Save
    >> dialog)
    >>
    >> Access doesn't usually work correctly with FM20.DLL anyhow: why have you
    >> got
    >> that reference?
    >>
    >> The general rule is to "starve" your references: only have the bare
    >> minimum
    >> as much as possible.
    >>
    >> --
    >> Doug Steele, Microsoft Access MVP
    >> http://I.Am/DougSteele
    >> (no private e-mails, please)
    >>
    >>
    >> "Rainer" <Rainer.Faller@exida.com> wrote in message
    >> news:1151910503.893423.21310@p79g2000cwp.googlegroups.com...
    >> > Hi,
    >> >
    >> > We have an MS Access application that works fine on US and European
    >> > Access installations but not on Japanese installations. Simple forms
    >> > work fine, but forms that contain subforms with event programming give
    >> > errors for each event. Our Japanese customer translated one of the
    >> > error message as follows:
    >> >
    >> > When Event, the formula that I appointed in a property, at the time of
    >> > resize, an error occurred:
    >> > When SafetyCaseDB communicated with an OLE server or ActiveX control,
    >> > an error occurred.
    >> >
    >> > We can reproduce it on multiple japanese installations. We checked all
    >> > references on a Japanese installation and they are fine. We can
    >> > recompile the program without compile time error. We gave every
    >> > subroutine / function an explicit reference like VBA.Left. Still the
    >> > help text to the error message leads to the MS Knowledgebase, entry
    >> > 283806, which says that a DLL is missing.
    >> >
    >> > To compile successfully the application requires references to the
    >> > following DLLs / OCXs:
    >> >
    >> > MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
    >> > MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
    >> > MSCOMCTL.OCX
    >> > FM20.DLL
    >> > vbscript.dll\3
    >> >
    >> > Thank you all for the help,
    >> >
    >> > Rainer
    >> >

    >
     
  6. david epsom dot com dot au

    david epsom dot com dot au
    Expand Collapse
    Guest

    > MSCOMCTL.OCX: yes, unfortunately if you're using TreeViews or ListViews,
    > you have no choice but to include the control


    ??? you don't need the type library to use the control, any
    more than you do for Word (or calendar) ???, it just makes
    it easier ??? Adding the object to a form adds the type library,
    but you can remove the type library and use late binding
    techniques if you want to??? Removing the type library
    doesn't make the object work if the object is not right, but
    lets other code work correctly?

    Does the subform or form have one of these objects? The
    error sounds more like an Access error than a VBA error,
    so it could be the link between the form and an active
    X control that has failed, rather than a failure while
    searching the type libraries.

    (david)



    "Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
    news:e4aUzDunGHA.2264@TK2MSFTNGP04.phx.gbl...
    > I'm very surprised that you can't remove the FM20.DLL. You might try
    > creating a new database and importing all of the objects from your
    > existing database into the new one (the references won't be imported: if
    > you don't have a required reference, you'll know when you try to compile
    > the application)
    >
    > MSCOMCTL.OCX: yes, unfortunately if you're using TreeViews or ListViews,
    > you have no choice but to include the control (sorry, I misread, and
    > thought you were using MSCOMDLG.OCX)
    >
    > Once your application is working, you really don't need the syntax
    > checking that early binding provides. It's typical to add the reference,
    > develop the application, then remove the reference before distributing the
    > application. If your code uses any of the intrinsic constants that come
    > from the reference (xlRight, wdPromptToSaveChanges and so on), you either
    > have to define the constants as Public in a module in your application, or
    > replace them with the actual value (my vote is the former).
    >
    > --
    > Doug Steele, Microsoft Access MVP
    > http://I.Am/DougSteele
    > (no private e-mails, please)
    >
    >
    > "Rainer" <Rainer.Faller@exida.com> wrote in message
    > news:1151946155.494005.183450@75g2000cwc.googlegroups.com...
    >> Doug,
    >>
    >> thank you for your suggestions.
    >>
    >> My major concern is FM20.DLL. We have no clue why we have it. The
    >> application developed over years. Access doesn't allow us to remove the
    >> reference ('in use'). Any hint how to get rid of it?
    >>
    >> Concerning MSCOMCTL.OCX: We need it, as we make extensive use of
    >> TreeViews all over the program.
    >>
    >> The other references, we can replace by late binding. But wouldn't we
    >> miss the syntax check by the VBA p-code compiler?
    >>
    >> Thanks, Rainer
    >>
    >> Douglas J. Steele schrieb:
    >>
    >>> Do you really need all those references?
    >>>
    >>> Consider removing the references to Word, Excel and the VBScript
    >>> library,
    >>> and using Late Binding instead.
    >>>
    >>> Consider removing the reference to MSCOMCTL.OCX and using API calls
    >>> instead
    >>> (see http://www.mvps.org/access/api/api0001.htm at "The Access Web" if
    >>> you've only got that reference for the standard Windows File Open/File
    >>> Save
    >>> dialog)
    >>>
    >>> Access doesn't usually work correctly with FM20.DLL anyhow: why have you
    >>> got
    >>> that reference?
    >>>
    >>> The general rule is to "starve" your references: only have the bare
    >>> minimum
    >>> as much as possible.
    >>>
    >>> --
    >>> Doug Steele, Microsoft Access MVP
    >>> http://I.Am/DougSteele
    >>> (no private e-mails, please)
    >>>
    >>>
    >>> "Rainer" <Rainer.Faller@exida.com> wrote in message
    >>> news:1151910503.893423.21310@p79g2000cwp.googlegroups.com...
    >>> > Hi,
    >>> >
    >>> > We have an MS Access application that works fine on US and European
    >>> > Access installations but not on Japanese installations. Simple forms
    >>> > work fine, but forms that contain subforms with event programming give
    >>> > errors for each event. Our Japanese customer translated one of the
    >>> > error message as follows:
    >>> >
    >>> > When Event, the formula that I appointed in a property, at the time of
    >>> > resize, an error occurred:
    >>> > When SafetyCaseDB communicated with an OLE server or ActiveX control,
    >>> > an error occurred.
    >>> >
    >>> > We can reproduce it on multiple japanese installations. We checked all
    >>> > references on a Japanese installation and they are fine. We can
    >>> > recompile the program without compile time error. We gave every
    >>> > subroutine / function an explicit reference like VBA.Left. Still the
    >>> > help text to the error message leads to the MS Knowledgebase, entry
    >>> > 283806, which says that a DLL is missing.
    >>> >
    >>> > To compile successfully the application requires references to the
    >>> > following DLLs / OCXs:
    >>> >
    >>> > MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
    >>> > MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
    >>> > MSCOMCTL.OCX
    >>> > FM20.DLL
    >>> > vbscript.dll\3
    >>> >
    >>> > Thank you all for the help,
    >>> >
    >>> > Rainer
    >>> >

    >>

    >
    >
     
  7. Douglas J Steele

    Douglas J Steele
    Expand Collapse
    Guest

    "david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
    news:eTj45q2nGHA.764@TK2MSFTNGP03.phx.gbl...
    > > MSCOMCTL.OCX: yes, unfortunately if you're using TreeViews or ListViews,
    > > you have no choice but to include the control

    >
    > ??? you don't need the type library to use the control, any
    > more than you do for Word (or calendar) ???, it just makes
    > it easier ??? Adding the object to a form adds the type library,
    > but you can remove the type library and use late binding
    > techniques if you want to??? Removing the type library
    > doesn't make the object work if the object is not right, but
    > lets other code work correctly?


    David: If you know of some way to have TreeViews or ListViews without having
    to have a reference to MSCOMCTL.OCX, I'd love to know of it!

    --
    Doug Steele, Microsoft Access MVP
    http://I.Am/DougSteele
    (no e-mails, please!)
     
  8. Rainer

    Rainer
    Expand Collapse
    Guest

    Doug,

    I'm following your advise and did copy all objects into an empty
    database. So far I got rid of FM20.DLL. Thanks. I had no chance yet to
    test it on a Japanese installation.

    However, I don't get our menus and popup menus over. How can I do that?

    Rainer

    Douglas J. Steele schrieb:

    > I'm very surprised that you can't remove the FM20.DLL. You might try
    > creating a new database and importing all of the objects from your existing
    > database into the new one (the references won't be imported: if you don't
    > have a required reference, you'll know when you try to compile the
    > application)
    >
    > MSCOMCTL.OCX: yes, unfortunately if you're using TreeViews or ListViews, you
    > have no choice but to include the control (sorry, I misread, and thought you
    > were using MSCOMDLG.OCX)
    >
    > Once your application is working, you really don't need the syntax checking
    > that early binding provides. It's typical to add the reference, develop the
    > application, then remove the reference before distributing the application.
    > If your code uses any of the intrinsic constants that come from the
    > reference (xlRight, wdPromptToSaveChanges and so on), you either have to
    > define the constants as Public in a module in your application, or replace
    > them with the actual value (my vote is the former).
    >
    > --
    > Doug Steele, Microsoft Access MVP
    > http://I.Am/DougSteele
    > (no private e-mails, please)
    >
    >
    > "Rainer" <Rainer.Faller@exida.com> wrote in message
    > news:1151946155.494005.183450@75g2000cwc.googlegroups.com...
    > > Doug,
    > >
    > > thank you for your suggestions.
    > >
    > > My major concern is FM20.DLL. We have no clue why we have it. The
    > > application developed over years. Access doesn't allow us to remove the
    > > reference ('in use'). Any hint how to get rid of it?
    > >
    > > Concerning MSCOMCTL.OCX: We need it, as we make extensive use of
    > > TreeViews all over the program.
    > >
    > > The other references, we can replace by late binding. But wouldn't we
    > > miss the syntax check by the VBA p-code compiler?
    > >
    > > Thanks, Rainer
    > >
    > > Douglas J. Steele schrieb:
    > >
    > >> Do you really need all those references?
    > >>
    > >> Consider removing the references to Word, Excel and the VBScript library,
    > >> and using Late Binding instead.
    > >>
    > >> Consider removing the reference to MSCOMCTL.OCX and using API calls
    > >> instead
    > >> (see http://www.mvps.org/access/api/api0001.htm at "The Access Web" if
    > >> you've only got that reference for the standard Windows File Open/File
    > >> Save
    > >> dialog)
    > >>
    > >> Access doesn't usually work correctly with FM20.DLL anyhow: why have you
    > >> got
    > >> that reference?
    > >>
    > >> The general rule is to "starve" your references: only have the bare
    > >> minimum
    > >> as much as possible.
    > >>
    > >> --
    > >> Doug Steele, Microsoft Access MVP
    > >> http://I.Am/DougSteele
    > >> (no private e-mails, please)
    > >>
    > >>
    > >> "Rainer" <Rainer.Faller@exida.com> wrote in message
    > >> news:1151910503.893423.21310@p79g2000cwp.googlegroups.com...
    > >> > Hi,
    > >> >
    > >> > We have an MS Access application that works fine on US and European
    > >> > Access installations but not on Japanese installations. Simple forms
    > >> > work fine, but forms that contain subforms with event programming give
    > >> > errors for each event. Our Japanese customer translated one of the
    > >> > error message as follows:
    > >> >
    > >> > When Event, the formula that I appointed in a property, at the time of
    > >> > resize, an error occurred:
    > >> > When SafetyCaseDB communicated with an OLE server or ActiveX control,
    > >> > an error occurred.
    > >> >
    > >> > We can reproduce it on multiple japanese installations. We checked all
    > >> > references on a Japanese installation and they are fine. We can
    > >> > recompile the program without compile time error. We gave every
    > >> > subroutine / function an explicit reference like VBA.Left. Still the
    > >> > help text to the error message leads to the MS Knowledgebase, entry
    > >> > 283806, which says that a DLL is missing.
    > >> >
    > >> > To compile successfully the application requires references to the
    > >> > following DLLs / OCXs:
    > >> >
    > >> > MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
    > >> > MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
    > >> > MSCOMCTL.OCX
    > >> > FM20.DLL
    > >> > vbscript.dll\3
    > >> >
    > >> > Thank you all for the help,
    > >> >
    > >> > Rainer
    > >> >

    > >
     
  9. Rainer

    Rainer
    Expand Collapse
    Guest

    David,

    No, the failing subforms don't have treeviews. They only use standard
    ACCESS objects.

    We kept the treeviews in separate forms. We wanted to encapsulate the
    use of additional DLLs as we did fear to run into problems with non
    standard DLLs. Funny enough, they work on the Japanese installation.

    Kind regards

    Rainer

    david epsom dot com dot au schrieb:

    > > MSCOMCTL.OCX: yes, unfortunately if you're using TreeViews or ListViews,
    > > you have no choice but to include the control

    >
    > ??? you don't need the type library to use the control, any
    > more than you do for Word (or calendar) ???, it just makes
    > it easier ??? Adding the object to a form adds the type library,
    > but you can remove the type library and use late binding
    > techniques if you want to??? Removing the type library
    > doesn't make the object work if the object is not right, but
    > lets other code work correctly?
    >
    > Does the subform or form have one of these objects? The
    > error sounds more like an Access error than a VBA error,
    > so it could be the link between the form and an active
    > X control that has failed, rather than a failure while
    > searching the type libraries.
    >
    > (david)
    >
    >
    >
    > "Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
    > news:e4aUzDunGHA.2264@TK2MSFTNGP04.phx.gbl...
    > > I'm very surprised that you can't remove the FM20.DLL. You might try
    > > creating a new database and importing all of the objects from your
    > > existing database into the new one (the references won't be imported: if
    > > you don't have a required reference, you'll know when you try to compile
    > > the application)
    > >
    > > MSCOMCTL.OCX: yes, unfortunately if you're using TreeViews or ListViews,
    > > you have no choice but to include the control (sorry, I misread, and
    > > thought you were using MSCOMDLG.OCX)
    > >
    > > Once your application is working, you really don't need the syntax
    > > checking that early binding provides. It's typical to add the reference,
    > > develop the application, then remove the reference before distributing the
    > > application. If your code uses any of the intrinsic constants that come
    > > from the reference (xlRight, wdPromptToSaveChanges and so on), you either
    > > have to define the constants as Public in a module in your application, or
    > > replace them with the actual value (my vote is the former).
    > >
    > > --
    > > Doug Steele, Microsoft Access MVP
    > > http://I.Am/DougSteele
    > > (no private e-mails, please)
    > >
    > >
    > > "Rainer" <Rainer.Faller@exida.com> wrote in message
    > > news:1151946155.494005.183450@75g2000cwc.googlegroups.com...
    > >> Doug,
    > >>
    > >> thank you for your suggestions.
    > >>
    > >> My major concern is FM20.DLL. We have no clue why we have it. The
    > >> application developed over years. Access doesn't allow us to remove the
    > >> reference ('in use'). Any hint how to get rid of it?
    > >>
    > >> Concerning MSCOMCTL.OCX: We need it, as we make extensive use of
    > >> TreeViews all over the program.
    > >>
    > >> The other references, we can replace by late binding. But wouldn't we
    > >> miss the syntax check by the VBA p-code compiler?
    > >>
    > >> Thanks, Rainer
    > >>
    > >> Douglas J. Steele schrieb:
    > >>
    > >>> Do you really need all those references?
    > >>>
    > >>> Consider removing the references to Word, Excel and the VBScript
    > >>> library,
    > >>> and using Late Binding instead.
    > >>>
    > >>> Consider removing the reference to MSCOMCTL.OCX and using API calls
    > >>> instead
    > >>> (see http://www.mvps.org/access/api/api0001.htm at "The Access Web" if
    > >>> you've only got that reference for the standard Windows File Open/File
    > >>> Save
    > >>> dialog)
    > >>>
    > >>> Access doesn't usually work correctly with FM20.DLL anyhow: why have you
    > >>> got
    > >>> that reference?
    > >>>
    > >>> The general rule is to "starve" your references: only have the bare
    > >>> minimum
    > >>> as much as possible.
    > >>>
    > >>> --
    > >>> Doug Steele, Microsoft Access MVP
    > >>> http://I.Am/DougSteele
    > >>> (no private e-mails, please)
    > >>>
    > >>>
    > >>> "Rainer" <Rainer.Faller@exida.com> wrote in message
    > >>> news:1151910503.893423.21310@p79g2000cwp.googlegroups.com...
    > >>> > Hi,
    > >>> >
    > >>> > We have an MS Access application that works fine on US and European
    > >>> > Access installations but not on Japanese installations. Simple forms
    > >>> > work fine, but forms that contain subforms with event programming give
    > >>> > errors for each event. Our Japanese customer translated one of the
    > >>> > error message as follows:
    > >>> >
    > >>> > When Event, the formula that I appointed in a property, at the time of
    > >>> > resize, an error occurred:
    > >>> > When SafetyCaseDB communicated with an OLE server or ActiveX control,
    > >>> > an error occurred.
    > >>> >
    > >>> > We can reproduce it on multiple japanese installations. We checked all
    > >>> > references on a Japanese installation and they are fine. We can
    > >>> > recompile the program without compile time error. We gave every
    > >>> > subroutine / function an explicit reference like VBA.Left. Still the
    > >>> > help text to the error message leads to the MS Knowledgebase, entry
    > >>> > 283806, which says that a DLL is missing.
    > >>> >
    > >>> > To compile successfully the application requires references to the
    > >>> > following DLLs / OCXs:
    > >>> >
    > >>> > MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
    > >>> > MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
    > >>> > MSCOMCTL.OCX
    > >>> > FM20.DLL
    > >>> > vbscript.dll\3
    > >>> >
    > >>> > Thank you all for the help,
    > >>> >
    > >>> > Rainer
    > >>> >
    > >>

    > >
    > >
     
  10. Douglas J Steele

    Douglas J Steele
    Expand Collapse
    Guest

    They're stored in one of the system tables, but off the top of my head, I'm
    afraid I don't remember which one.

    You might try posting this as a new question: many people avoid responding
    to posts that have been going back and forth for this long.

    --
    Doug Steele, Microsoft Access MVP
    http://I.Am/DougSteele
    (no e-mails, please!)


    "Rainer" <Rainer.Faller@exida.com> wrote in message
    news:1152035025.930864.294170@a14g2000cwb.googlegroups.com...
    > Doug,
    >
    > I'm following your advise and did copy all objects into an empty
    > database. So far I got rid of FM20.DLL. Thanks. I had no chance yet to
    > test it on a Japanese installation.
    >
    > However, I don't get our menus and popup menus over. How can I do that?
    >
    > Rainer
    >
    > Douglas J. Steele schrieb:
    >
    > > I'm very surprised that you can't remove the FM20.DLL. You might try
    > > creating a new database and importing all of the objects from your

    existing
    > > database into the new one (the references won't be imported: if you

    don't
    > > have a required reference, you'll know when you try to compile the
    > > application)
    > >
    > > MSCOMCTL.OCX: yes, unfortunately if you're using TreeViews or ListViews,

    you
    > > have no choice but to include the control (sorry, I misread, and thought

    you
    > > were using MSCOMDLG.OCX)
    > >
    > > Once your application is working, you really don't need the syntax

    checking
    > > that early binding provides. It's typical to add the reference, develop

    the
    > > application, then remove the reference before distributing the

    application.
    > > If your code uses any of the intrinsic constants that come from the
    > > reference (xlRight, wdPromptToSaveChanges and so on), you either have to
    > > define the constants as Public in a module in your application, or

    replace
    > > them with the actual value (my vote is the former).
    > >
    > > --
    > > Doug Steele, Microsoft Access MVP
    > > http://I.Am/DougSteele
    > > (no private e-mails, please)
    > >
    > >
    > > "Rainer" <Rainer.Faller@exida.com> wrote in message
    > > news:1151946155.494005.183450@75g2000cwc.googlegroups.com...
    > > > Doug,
    > > >
    > > > thank you for your suggestions.
    > > >
    > > > My major concern is FM20.DLL. We have no clue why we have it. The
    > > > application developed over years. Access doesn't allow us to remove

    the
    > > > reference ('in use'). Any hint how to get rid of it?
    > > >
    > > > Concerning MSCOMCTL.OCX: We need it, as we make extensive use of
    > > > TreeViews all over the program.
    > > >
    > > > The other references, we can replace by late binding. But wouldn't we
    > > > miss the syntax check by the VBA p-code compiler?
    > > >
    > > > Thanks, Rainer
    > > >
    > > > Douglas J. Steele schrieb:
    > > >
    > > >> Do you really need all those references?
    > > >>
    > > >> Consider removing the references to Word, Excel and the VBScript

    library,
    > > >> and using Late Binding instead.
    > > >>
    > > >> Consider removing the reference to MSCOMCTL.OCX and using API calls
    > > >> instead
    > > >> (see http://www.mvps.org/access/api/api0001.htm at "The Access Web"

    if
    > > >> you've only got that reference for the standard Windows File

    Open/File
    > > >> Save
    > > >> dialog)
    > > >>
    > > >> Access doesn't usually work correctly with FM20.DLL anyhow: why have

    you
    > > >> got
    > > >> that reference?
    > > >>
    > > >> The general rule is to "starve" your references: only have the bare
    > > >> minimum
    > > >> as much as possible.
    > > >>
    > > >> --
    > > >> Doug Steele, Microsoft Access MVP
    > > >> http://I.Am/DougSteele
    > > >> (no private e-mails, please)
    > > >>
    > > >>
    > > >> "Rainer" <Rainer.Faller@exida.com> wrote in message
    > > >> news:1151910503.893423.21310@p79g2000cwp.googlegroups.com...
    > > >> > Hi,
    > > >> >
    > > >> > We have an MS Access application that works fine on US and European
    > > >> > Access installations but not on Japanese installations. Simple

    forms
    > > >> > work fine, but forms that contain subforms with event programming

    give
    > > >> > errors for each event. Our Japanese customer translated one of the
    > > >> > error message as follows:
    > > >> >
    > > >> > When Event, the formula that I appointed in a property, at the time

    of
    > > >> > resize, an error occurred:
    > > >> > When SafetyCaseDB communicated with an OLE server or ActiveX

    control,
    > > >> > an error occurred.
    > > >> >
    > > >> > We can reproduce it on multiple japanese installations. We checked

    all
    > > >> > references on a Japanese installation and they are fine. We can
    > > >> > recompile the program without compile time error. We gave every
    > > >> > subroutine / function an explicit reference like VBA.Left. Still

    the
    > > >> > help text to the error message leads to the MS Knowledgebase, entry
    > > >> > 283806, which says that a DLL is missing.
    > > >> >
    > > >> > To compile successfully the application requires references to the
    > > >> > following DLLs / OCXs:
    > > >> >
    > > >> > MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
    > > >> > MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
    > > >> > MSCOMCTL.OCX
    > > >> > FM20.DLL
    > > >> > vbscript.dll\3
    > > >> >
    > > >> > Thank you all for the help,
    > > >> >
    > > >> > Rainer
    > > >> >
    > > >

    >
     
  11. Douglas J Steele

    Douglas J Steele
    Expand Collapse
    Guest

    Actually, I just remembered that when you're importing from one database to
    another, you can click on the Options button, and you'll be presented with
    an option to import the Menus and Toolbars.

    --
    Doug Steele, Microsoft Access MVP
    http://I.Am/DougSteele
    (no e-mails, please!)


    "Douglas J Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
    news:%23tu4Dm5nGHA.4604@TK2MSFTNGP02.phx.gbl...
    > They're stored in one of the system tables, but off the top of my head,

    I'm
    > afraid I don't remember which one.
    >
    > You might try posting this as a new question: many people avoid responding
    > to posts that have been going back and forth for this long.
    >
    > --
    > Doug Steele, Microsoft Access MVP
    > http://I.Am/DougSteele
    > (no e-mails, please!)
    >
    >
    > "Rainer" <Rainer.Faller@exida.com> wrote in message
    > news:1152035025.930864.294170@a14g2000cwb.googlegroups.com...
    > > Doug,
    > >
    > > I'm following your advise and did copy all objects into an empty
    > > database. So far I got rid of FM20.DLL. Thanks. I had no chance yet to
    > > test it on a Japanese installation.
    > >
    > > However, I don't get our menus and popup menus over. How can I do that?
    > >
    > > Rainer
    > >
    > > Douglas J. Steele schrieb:
    > >
    > > > I'm very surprised that you can't remove the FM20.DLL. You might try
    > > > creating a new database and importing all of the objects from your

    > existing
    > > > database into the new one (the references won't be imported: if you

    > don't
    > > > have a required reference, you'll know when you try to compile the
    > > > application)
    > > >
    > > > MSCOMCTL.OCX: yes, unfortunately if you're using TreeViews or

    ListViews,
    > you
    > > > have no choice but to include the control (sorry, I misread, and

    thought
    > you
    > > > were using MSCOMDLG.OCX)
    > > >
    > > > Once your application is working, you really don't need the syntax

    > checking
    > > > that early binding provides. It's typical to add the reference,

    develop
    > the
    > > > application, then remove the reference before distributing the

    > application.
    > > > If your code uses any of the intrinsic constants that come from the
    > > > reference (xlRight, wdPromptToSaveChanges and so on), you either have

    to
    > > > define the constants as Public in a module in your application, or

    > replace
    > > > them with the actual value (my vote is the former).
    > > >
    > > > --
    > > > Doug Steele, Microsoft Access MVP
    > > > http://I.Am/DougSteele
    > > > (no private e-mails, please)
    > > >
    > > >
    > > > "Rainer" <Rainer.Faller@exida.com> wrote in message
    > > > news:1151946155.494005.183450@75g2000cwc.googlegroups.com...
    > > > > Doug,
    > > > >
    > > > > thank you for your suggestions.
    > > > >
    > > > > My major concern is FM20.DLL. We have no clue why we have it. The
    > > > > application developed over years. Access doesn't allow us to remove

    > the
    > > > > reference ('in use'). Any hint how to get rid of it?
    > > > >
    > > > > Concerning MSCOMCTL.OCX: We need it, as we make extensive use of
    > > > > TreeViews all over the program.
    > > > >
    > > > > The other references, we can replace by late binding. But wouldn't

    we
    > > > > miss the syntax check by the VBA p-code compiler?
    > > > >
    > > > > Thanks, Rainer
    > > > >
    > > > > Douglas J. Steele schrieb:
    > > > >
    > > > >> Do you really need all those references?
    > > > >>
    > > > >> Consider removing the references to Word, Excel and the VBScript

    > library,
    > > > >> and using Late Binding instead.
    > > > >>
    > > > >> Consider removing the reference to MSCOMCTL.OCX and using API calls
    > > > >> instead
    > > > >> (see http://www.mvps.org/access/api/api0001.htm at "The Access Web"

    > if
    > > > >> you've only got that reference for the standard Windows File

    > Open/File
    > > > >> Save
    > > > >> dialog)
    > > > >>
    > > > >> Access doesn't usually work correctly with FM20.DLL anyhow: why

    have
    > you
    > > > >> got
    > > > >> that reference?
    > > > >>
    > > > >> The general rule is to "starve" your references: only have the bare
    > > > >> minimum
    > > > >> as much as possible.
    > > > >>
    > > > >> --
    > > > >> Doug Steele, Microsoft Access MVP
    > > > >> http://I.Am/DougSteele
    > > > >> (no private e-mails, please)
    > > > >>
    > > > >>
    > > > >> "Rainer" <Rainer.Faller@exida.com> wrote in message
    > > > >> news:1151910503.893423.21310@p79g2000cwp.googlegroups.com...
    > > > >> > Hi,
    > > > >> >
    > > > >> > We have an MS Access application that works fine on US and

    European
    > > > >> > Access installations but not on Japanese installations. Simple

    > forms
    > > > >> > work fine, but forms that contain subforms with event programming

    > give
    > > > >> > errors for each event. Our Japanese customer translated one of

    the
    > > > >> > error message as follows:
    > > > >> >
    > > > >> > When Event, the formula that I appointed in a property, at the

    time
    > of
    > > > >> > resize, an error occurred:
    > > > >> > When SafetyCaseDB communicated with an OLE server or ActiveX

    > control,
    > > > >> > an error occurred.
    > > > >> >
    > > > >> > We can reproduce it on multiple japanese installations. We

    checked
    > all
    > > > >> > references on a Japanese installation and they are fine. We can
    > > > >> > recompile the program without compile time error. We gave every
    > > > >> > subroutine / function an explicit reference like VBA.Left. Still

    > the
    > > > >> > help text to the error message leads to the MS Knowledgebase,

    entry
    > > > >> > 283806, which says that a DLL is missing.
    > > > >> >
    > > > >> > To compile successfully the application requires references to

    the
    > > > >> > following DLLs / OCXs:
    > > > >> >
    > > > >> > MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
    > > > >> > MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
    > > > >> > MSCOMCTL.OCX
    > > > >> > FM20.DLL
    > > > >> > vbscript.dll\3
    > > > >> >
    > > > >> > Thank you all for the help,
    > > > >> >
    > > > >> > Rainer
    > > > >> >
    > > > >

    > >

    >
    >
     
  12. david epsom dot com dot au

    david epsom dot com dot au
    Expand Collapse
    Guest

    When you add a mscomctl.ocx to a form, Access adds
    mscomctl.ocx as a 'reference' in the VBA project.

    If you view the object browser, you will see mscomctlLib.

    You can remove the 'reference' to mscomctl.ocx, which will
    remove mscomctlLib from the object browser, but will not
    remove the mscomctl.ocx object from your form.

    If you remove the 'reference' to mscomctl.ocx, you loose
    msconctlLib from the object browser, and you will have to
    use late binding techniques with the mscomctl object on
    your form.

    If you remove the reference, you will not get the 'broken
    reference' behaviour in VBA, where VBA fails while searching
    through the type libraries to see if there are any function
    or method declarations that over-ride the VBA function and
    method definitions.

    If the object on the form is not declared and registered
    as expected, the object on the form will not work, but if
    you are not using the type library, that won't kill the
    whole project.

    I always use this technique with other Active X objects.
    (david)



    "Douglas J Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
    news:%23Axz7A3nGHA.3784@TK2MSFTNGP04.phx.gbl...
    > "david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
    > news:eTj45q2nGHA.764@TK2MSFTNGP03.phx.gbl...
    >> > MSCOMCTL.OCX: yes, unfortunately if you're using TreeViews or
    >> > ListViews,
    >> > you have no choice but to include the control

    >>
    >> ??? you don't need the type library to use the control, any
    >> more than you do for Word (or calendar) ???, it just makes
    >> it easier ??? Adding the object to a form adds the type library,
    >> but you can remove the type library and use late binding
    >> techniques if you want to??? Removing the type library
    >> doesn't make the object work if the object is not right, but
    >> lets other code work correctly?

    >
    > David: If you know of some way to have TreeViews or ListViews without
    > having
    > to have a reference to MSCOMCTL.OCX, I'd love to know of it!
    >
    > --
    > Doug Steele, Microsoft Access MVP
    > http://I.Am/DougSteele
    > (no e-mails, please!)
    >
    >
    >
     
  13. david epsom dot com dot au

    david epsom dot com dot au
    Expand Collapse
    Guest

    What is the error number?

    Does the error occur on an actual line of code?
    (or is it a 'form' error?)

    (david)

    "Rainer" <Rainer.Faller@exida.com> wrote in message
    news:1152035537.351067.13540@a14g2000cwb.googlegroups.com...
    > David,
    >
    >, please)
    >> >>>
    >> >>>
    >> >>> "Rainer" <Rainer.Faller@exida.com> wrote in message
    >> >>> news:1151910503.893423.21310@p79g2000cwp.googlegroups.com...
    >> >>> > Hi,
    >> >>> >
    >> >>> > We have an MS Access application that works fine on US and European
    >> >>> > Access installations but not on Japanese installations. Simple
    >> >>> > forms
    >> >>> > work fine, but forms that contain subforms with event programming
    >> >>> > give
    >> >>> > errors for each event. Our Japanese customer translated one of the
    >> >>> > error message as follows:
    >> >>> >
    >> >>> > When Event, the formula that I appointed in a property, at the time
    >> >>> > of
    >> >>> > resize, an error occurred:
    >> >>> > When SafetyCaseDB communicated with an OLE server or ActiveX
    >> >>> > control,
    >> >>> > an error occurred.
    >> >>> >
    >> >>> > We can reproduce it on multiple japanese installations. We checked
    >> >>> > all
    >> >>> > references on a Japanese installation and they are fine. We can
    >> >>> > recompile the program without compile time error. We gave every
    >> >>> > subroutine / function an explicit reference like VBA.Left. Still
    >> >>> > the
    >> >>> > help text to the error message leads to the MS Knowledgebase, entry
    >> >>> > 283806, which says that a DLL is missing.
    >> >>> >
    >> >>> > To compile successfully the application requires references to the
    >> >>> > following DLLs / OCXs:
    >> >>> >
    >> >>> > MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
    >> >>> > MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
    >> >>> > MSCOMCTL.OCX
    >> >>> > FM20.DLL
    >> >>> > vbscript.dll\3
    >> >>> >
    >> >>> > Thank you all for the help,
    >> >>> >
    >> >>> > Rainer
    >> >>> >
    >> >>
    >> >
    >> >

    >
     
  14. Douglas J Steele

    Douglas J Steele
    Expand Collapse
    Guest

    I'd never tried doing that. Thanks!

    --
    Doug Steele, Microsoft Access MVP
    http://I.Am/DougSteele
    (no e-mails, please!)


    "david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
    news:eXdLio8nGHA.4952@TK2MSFTNGP02.phx.gbl...
    > When you add a mscomctl.ocx to a form, Access adds
    > mscomctl.ocx as a 'reference' in the VBA project.
    >
    > If you view the object browser, you will see mscomctlLib.
    >
    > You can remove the 'reference' to mscomctl.ocx, which will
    > remove mscomctlLib from the object browser, but will not
    > remove the mscomctl.ocx object from your form.
    >
    > If you remove the 'reference' to mscomctl.ocx, you loose
    > msconctlLib from the object browser, and you will have to
    > use late binding techniques with the mscomctl object on
    > your form.
    >
    > If you remove the reference, you will not get the 'broken
    > reference' behaviour in VBA, where VBA fails while searching
    > through the type libraries to see if there are any function
    > or method declarations that over-ride the VBA function and
    > method definitions.
    >
    > If the object on the form is not declared and registered
    > as expected, the object on the form will not work, but if
    > you are not using the type library, that won't kill the
    > whole project.
    >
    > I always use this technique with other Active X objects.
    > (david)
    >
    >
    >
    > "Douglas J Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
    > news:%23Axz7A3nGHA.3784@TK2MSFTNGP04.phx.gbl...
    > > "david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
    > > news:eTj45q2nGHA.764@TK2MSFTNGP03.phx.gbl...
    > >> > MSCOMCTL.OCX: yes, unfortunately if you're using TreeViews or
    > >> > ListViews,
    > >> > you have no choice but to include the control
    > >>
    > >> ??? you don't need the type library to use the control, any
    > >> more than you do for Word (or calendar) ???, it just makes
    > >> it easier ??? Adding the object to a form adds the type library,
    > >> but you can remove the type library and use late binding
    > >> techniques if you want to??? Removing the type library
    > >> doesn't make the object work if the object is not right, but
    > >> lets other code work correctly?

    > >
    > > David: If you know of some way to have TreeViews or ListViews without
    > > having
    > > to have a reference to MSCOMCTL.OCX, I'd love to know of it!
    > >
    > > --
    > > Doug Steele, Microsoft Access MVP
    > > http://I.Am/DougSteele
    > > (no e-mails, please!)
    > >
    > >
    > >

    >
    >
     
  15. david epsom dot com dot au

    david epsom dot com dot au
    Expand Collapse
    Guest

    http://support.microsoft.com/kb/907337/en-us

    ....

    "The expression On Click you entered as the event property setting produced
    the following error: A problem occurred while Microsoft Access was
    communicating with the OLE Server or ActiveX Control."

    ....
    this issue may occur if the following conditions are true:

    ....

    You run the VBA code on a computer that uses different non-Unicode language
    settings than the computer on which you created the event handler, the
    function, or the subroutine.

    ....


    (david)


    "david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
    news:ub33Gu8nGHA.4736@TK2MSFTNGP02.phx.gbl...
    > What is the error number?
    >
    > Does the error occur on an actual line of code?
    > (or is it a 'form' error?)
    >
    > (david)
    >
    > "Rainer" <Rainer.Faller@exida.com> wrote in message
    > news:1152035537.351067.13540@a14g2000cwb.googlegroups.com...
    >> David,
    >>
    >>, please)
    >>> >>>
    >>> >>>
    >>> >>> "Rainer" <Rainer.Faller@exida.com> wrote in message
    >>> >>> news:1151910503.893423.21310@p79g2000cwp.googlegroups.com...
    >>> >>> > Hi,
    >>> >>> >
    >>> >>> > We have an MS Access application that works fine on US and
    >>> >>> > European
    >>> >>> > Access installations but not on Japanese installations. Simple
    >>> >>> > forms
    >>> >>> > work fine, but forms that contain subforms with event programming
    >>> >>> > give
    >>> >>> > errors for each event. Our Japanese customer translated one of the
    >>> >>> > error message as follows:
    >>> >>> >
    >>> >>> > When Event, the formula that I appointed in a property, at the
    >>> >>> > time of
    >>> >>> > resize, an error occurred:
    >>> >>> > When SafetyCaseDB communicated with an OLE server or ActiveX
    >>> >>> > control,
    >>> >>> > an error occurred.
    >>> >>> >
    >>> >>> > We can reproduce it on multiple japanese installations. We checked
    >>> >>> > all
    >>> >>> > references on a Japanese installation and they are fine. We can
    >>> >>> > recompile the program without compile time error. We gave every
    >>> >>> > subroutine / function an explicit reference like VBA.Left. Still
    >>> >>> > the
    >>> >>> > help text to the error message leads to the MS Knowledgebase,
    >>> >>> > entry
    >>> >>> > 283806, which says that a DLL is missing.
    >>> >>> >
    >>> >>> > To compile successfully the application requires references to the
    >>> >>> > following DLLs / OCXs:
    >>> >>> >
    >>> >>> > MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
    >>> >>> > MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
    >>> >>> > MSCOMCTL.OCX
    >>> >>> > FM20.DLL
    >>> >>> > vbscript.dll\3
    >>> >>> >
    >>> >>> > Thank you all for the help,
    >>> >>> >
    >>> >>> > Rainer
    >>> >>> >
    >>> >>
    >>> >
    >>> >

    >>

    >
    >
     
  16. Rainer

    Rainer
    Expand Collapse
    Guest

    David,

    Thank you for the hint. Isn't that the normal situation when we develop
    on German and English machines, and then let the ACCESS application run
    on a Japanese machine?

    Can you explain what such non-Unicode language settings are and how to
    avoid them or set them correctly?

    Remark: (1) All text/memo fields in the tables have UniCode Compression
    ON. (2) The first time we encountered the problem with Japanese Access,
    we changed all controls from standard MS Sans Serif to Tahoma font, as
    there was another thread saying other fonts may result in unicode
    language problems.

    BTW, your hint on the import option made me import the menus.

    Kind regards

    Rainer

    david epsom dot com dot au schrieb:

    > http://support.microsoft.com/kb/907337/en-us
    >
    > ...
    >
    > "The expression On Click you entered as the event property setting produced
    > the following error: A problem occurred while Microsoft Access was
    > communicating with the OLE Server or ActiveX Control."
    >
    > ...
    > this issue may occur if the following conditions are true:
    >
    > ...
    >
    > You run the VBA code on a computer that uses different non-Unicode language
    > settings than the computer on which you created the event handler, the
    > function, or the subroutine.
    >
    > ...
    >
    >
    > (david)
    >
    >
    > "david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
    > news:ub33Gu8nGHA.4736@TK2MSFTNGP02.phx.gbl...
    > > What is the error number?
    > >
    > > Does the error occur on an actual line of code?
    > > (or is it a 'form' error?)
    > >
    > > (david)
    > >
    > > "Rainer" <Rainer.Faller@exida.com> wrote in message
    > > news:1152035537.351067.13540@a14g2000cwb.googlegroups.com...
    > >> David,
    > >>
    > >>, please)
    > >>> >>>
    > >>> >>>
    > >>> >>> "Rainer" <Rainer.Faller@exida.com> wrote in message
    > >>> >>> news:1151910503.893423.21310@p79g2000cwp.googlegroups.com...
    > >>> >>> > Hi,
    > >>> >>> >
    > >>> >>> > We have an MS Access application that works fine on US and
    > >>> >>> > European
    > >>> >>> > Access installations but not on Japanese installations. Simple
    > >>> >>> > forms
    > >>> >>> > work fine, but forms that contain subforms with event programming
    > >>> >>> > give
    > >>> >>> > errors for each event. Our Japanese customer translated one of the
    > >>> >>> > error message as follows:
    > >>> >>> >
    > >>> >>> > When Event, the formula that I appointed in a property, at the
    > >>> >>> > time of
    > >>> >>> > resize, an error occurred:
    > >>> >>> > When SafetyCaseDB communicated with an OLE server or ActiveX
    > >>> >>> > control,
    > >>> >>> > an error occurred.
    > >>> >>> >
    > >>> >>> > We can reproduce it on multiple japanese installations. We checked
    > >>> >>> > all
    > >>> >>> > references on a Japanese installation and they are fine. We can
    > >>> >>> > recompile the program without compile time error. We gave every
    > >>> >>> > subroutine / function an explicit reference like VBA.Left. Still
    > >>> >>> > the
    > >>> >>> > help text to the error message leads to the MS Knowledgebase,
    > >>> >>> > entry
    > >>> >>> > 283806, which says that a DLL is missing.
    > >>> >>> >
    > >>> >>> > To compile successfully the application requires references to the
    > >>> >>> > following DLLs / OCXs:
    > >>> >>> >
    > >>> >>> > MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
    > >>> >>> > MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
    > >>> >>> > MSCOMCTL.OCX
    > >>> >>> > FM20.DLL
    > >>> >>> > vbscript.dll\3
    > >>> >>> >
    > >>> >>> > Thank you all for the help,
    > >>> >>> >
    > >>> >>> > Rainer
    > >>> >>> >
    > >>> >>
    > >>> >
    > >>> >
    > >>

    > >
    > >
     
  17. Rainer

    Rainer
    Expand Collapse
    Guest

    David,

    my previous message didn't answer your question. There is no VBA error
    number indicated. The error occurs before I can set any breakpoint in
    the form's event code. It may be what you call "form error".

    Rainer

    david epsom dot com dot au schrieb:

    > What is the error number?
    >
    > Does the error occur on an actual line of code?
    > (or is it a 'form' error?)
    >
    > (david)
    >
    > "Rainer" <Rainer.Faller@exida.com> wrote in message
    > news:1152035537.351067.13540@a14g2000cwb.googlegroups.com...
    > > David,
    > >
    > >, please)
    > >> >>>
    > >> >>>
    > >> >>> "Rainer" <Rainer.Faller@exida.com> wrote in message
    > >> >>> news:1151910503.893423.21310@p79g2000cwp.googlegroups.com...
    > >> >>> > Hi,
    > >> >>> >
    > >> >>> > We have an MS Access application that works fine on US and European
    > >> >>> > Access installations but not on Japanese installations. Simple
    > >> >>> > forms
    > >> >>> > work fine, but forms that contain subforms with event programming
    > >> >>> > give
    > >> >>> > errors for each event. Our Japanese customer translated one of the
    > >> >>> > error message as follows:
    > >> >>> >
    > >> >>> > When Event, the formula that I appointed in a property, at the time
    > >> >>> > of
    > >> >>> > resize, an error occurred:
    > >> >>> > When SafetyCaseDB communicated with an OLE server or ActiveX
    > >> >>> > control,
    > >> >>> > an error occurred.
    > >> >>> >
    > >> >>> > We can reproduce it on multiple japanese installations. We checked
    > >> >>> > all
    > >> >>> > references on a Japanese installation and they are fine. We can
    > >> >>> > recompile the program without compile time error. We gave every
    > >> >>> > subroutine / function an explicit reference like VBA.Left. Still
    > >> >>> > the
    > >> >>> > help text to the error message leads to the MS Knowledgebase, entry
    > >> >>> > 283806, which says that a DLL is missing.
    > >> >>> >
    > >> >>> > To compile successfully the application requires references to the
    > >> >>> > following DLLs / OCXs:
    > >> >>> >
    > >> >>> > MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
    > >> >>> > MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
    > >> >>> > MSCOMCTL.OCX
    > >> >>> > FM20.DLL
    > >> >>> > vbscript.dll\3
    > >> >>> >
    > >> >>> > Thank you all for the help,
    > >> >>> >
    > >> >>> > Rainer
    > >> >>> >
    > >> >>
    > >> >
    > >> >

    > >
     
  18. Rainer

    Rainer
    Expand Collapse
    Guest

    David,

    I did overlook your link to the Microsoft knowledge space. I will
    follow what they advice.

    Thanks, Rainer

    david epsom dot com dot au schrieb:

    > http://support.microsoft.com/kb/907337/en-us
    >
    > ...
    >
    > "The expression On Click you entered as the event property setting produced
    > the following error: A problem occurred while Microsoft Access was
    > communicating with the OLE Server or ActiveX Control."
    >
    > ...
    > this issue may occur if the following conditions are true:
    >
    > ...
    >
    > You run the VBA code on a computer that uses different non-Unicode language
    > settings than the computer on which you created the event handler, the
    > function, or the subroutine.
    >
    > ...
    >
    >
    > (david)
    >
    >
    > "david epsom dot com dot au" <david@epsomdotcomdotau> wrote in message
    > news:ub33Gu8nGHA.4736@TK2MSFTNGP02.phx.gbl...
    > > What is the error number?
    > >
    > > Does the error occur on an actual line of code?
    > > (or is it a 'form' error?)
    > >
    > > (david)
    > >
    > > "Rainer" <Rainer.Faller@exida.com> wrote in message
    > > news:1152035537.351067.13540@a14g2000cwb.googlegroups.com...
    > >> David,
    > >>
    > >>, please)
    > >>> >>>
    > >>> >>>
    > >>> >>> "Rainer" <Rainer.Faller@exida.com> wrote in message
    > >>> >>> news:1151910503.893423.21310@p79g2000cwp.googlegroups.com...
    > >>> >>> > Hi,
    > >>> >>> >
    > >>> >>> > We have an MS Access application that works fine on US and
    > >>> >>> > European
    > >>> >>> > Access installations but not on Japanese installations. Simple
    > >>> >>> > forms
    > >>> >>> > work fine, but forms that contain subforms with event programming
    > >>> >>> > give
    > >>> >>> > errors for each event. Our Japanese customer translated one of the
    > >>> >>> > error message as follows:
    > >>> >>> >
    > >>> >>> > When Event, the formula that I appointed in a property, at the
    > >>> >>> > time of
    > >>> >>> > resize, an error occurred:
    > >>> >>> > When SafetyCaseDB communicated with an OLE server or ActiveX
    > >>> >>> > control,
    > >>> >>> > an error occurred.
    > >>> >>> >
    > >>> >>> > We can reproduce it on multiple japanese installations. We checked
    > >>> >>> > all
    > >>> >>> > references on a Japanese installation and they are fine. We can
    > >>> >>> > recompile the program without compile time error. We gave every
    > >>> >>> > subroutine / function an explicit reference like VBA.Left. Still
    > >>> >>> > the
    > >>> >>> > help text to the error message leads to the MS Knowledgebase,
    > >>> >>> > entry
    > >>> >>> > 283806, which says that a DLL is missing.
    > >>> >>> >
    > >>> >>> > To compile successfully the application requires references to the
    > >>> >>> > following DLLs / OCXs:
    > >>> >>> >
    > >>> >>> > MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
    > >>> >>> > MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
    > >>> >>> > MSCOMCTL.OCX
    > >>> >>> > FM20.DLL
    > >>> >>> > vbscript.dll\3
    > >>> >>> >
    > >>> >>> > Thank you all for the help,
    > >>> >>> >
    > >>> >>> > Rainer
    > >>> >>> >
    > >>> >>
    > >>> >
    > >>> >
    > >>

    > >
    > >
     
  19. david epsom dot com dot au

    david epsom dot com dot au
    Expand Collapse
    Guest

    This tends to indicate that you don't have an error
    in 'VBA', you have an error in 'Access', that is,
    you don't have a 'references' error. But I think
    the KB article clears up that question anyway.

    Access uses com based communications internally,
    and you've got trouble reading a property or raising
    an event, because the source and the sink are
    speaking different languages.

    I'd be looking at setting up a Japanese machine
    to do the build, or pushing MS to get a hotfix.

    (david)


    "Rainer" <Rainer.Faller@exida.com> wrote in message
    news:1152395084.464640.211140@p79g2000cwp.googlegroups.com...
    > David,
    >
    > my previous message didn't answer your question. There is no VBA error
    > number indicated. The error occurs before I can set any breakpoint in
    > the form's event code. It may be what you call "form error".
    >
    > Rainer
    >
    > david epsom dot com dot au schrieb:
    >
    >> What is the error number?
    >>
    >> Does the error occur on an actual line of code?
    >> (or is it a 'form' error?)
    >>
    >> (david)
    >>
    >> "Rainer" <Rainer.Faller@exida.com> wrote in message
    >> news:1152035537.351067.13540@a14g2000cwb.googlegroups.com...
    >> > David,
    >> >
    >> >, please)
    >> >> >>>
    >> >> >>>
    >> >> >>> "Rainer" <Rainer.Faller@exida.com> wrote in message
    >> >> >>> news:1151910503.893423.21310@p79g2000cwp.googlegroups.com...
    >> >> >>> > Hi,
    >> >> >>> >
    >> >> >>> > We have an MS Access application that works fine on US and
    >> >> >>> > European
    >> >> >>> > Access installations but not on Japanese installations. Simple
    >> >> >>> > forms
    >> >> >>> > work fine, but forms that contain subforms with event
    >> >> >>> > programming
    >> >> >>> > give
    >> >> >>> > errors for each event. Our Japanese customer translated one of
    >> >> >>> > the
    >> >> >>> > error message as follows:
    >> >> >>> >
    >> >> >>> > When Event, the formula that I appointed in a property, at the
    >> >> >>> > time
    >> >> >>> > of
    >> >> >>> > resize, an error occurred:
    >> >> >>> > When SafetyCaseDB communicated with an OLE server or ActiveX
    >> >> >>> > control,
    >> >> >>> > an error occurred.
    >> >> >>> >
    >> >> >>> > We can reproduce it on multiple japanese installations. We
    >> >> >>> > checked
    >> >> >>> > all
    >> >> >>> > references on a Japanese installation and they are fine. We can
    >> >> >>> > recompile the program without compile time error. We gave every
    >> >> >>> > subroutine / function an explicit reference like VBA.Left. Still
    >> >> >>> > the
    >> >> >>> > help text to the error message leads to the MS Knowledgebase,
    >> >> >>> > entry
    >> >> >>> > 283806, which says that a DLL is missing.
    >> >> >>> >
    >> >> >>> > To compile successfully the application requires references to
    >> >> >>> > the
    >> >> >>> > following DLLs / OCXs:
    >> >> >>> >
    >> >> >>> > MSACC9.OLB; msado27.tlb; dao360.dll; VBE6.DLL
    >> >> >>> > MSO9.DLL; EXCEL9.OLB; MSWORD9.OLB
    >> >> >>> > MSCOMCTL.OCX
    >> >> >>> > FM20.DLL
    >> >> >>> > vbscript.dll\3
    >> >> >>> >
    >> >> >>> > Thank you all for the help,
    >> >> >>> >
    >> >> >>> > Rainer
    >> >> >>> >
    >> >> >>
    >> >> >
    >> >> >
    >> >

    >
     

Share This Page