none
Open a report from MS-Access 2010 runtime version in vb.net windows application

    Question

  • In VB.Net, I am trying to open a report from MS-Access 2010 runtime version. But it is throwing error.

    The error is

    Retrieving the COM class factory for component with CLSID {73A4C9C1-D68D-11D0-98BF-00A0C90DC8D9} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)

    But in the full version of MS-Access it is working fine. How to fix this issue in the runtime version of MS-Access 2010 to view the report?

    Tuesday, August 14, 2012 9:08 AM

Answers

  • You cannot create an automated instance of the Access runtime.

    In fact to be more precise, the VERY important issue is this:

    If you open a copy of the runtime without passing a mdb/accdb file to open on the command line, the instance of Access starts up, and then:

    I don't have an open file – I will shut down

    (re-read the above over again – then read above again).

    What this means is that in fact you can create a running instance of the runtime, but the instant it is created and loaded – it THEN ALSO shuts down right away since no file name was passed on the command line. In fact this design is to thus allow/prevent stray instances of msacccess.exe running since if a user clicked on the runtime, they would have NO WAY to shut down that instance (the UI for the most part is hidden and not provided).

    What this means is you need to provide a valid file name when launching the access runtime.

    PROBLEM:
    You cannot provide a value file name when using create object. So the create object works, but then Access runtime says:

    Hey, no file open – I will shut down.

    In the FULL edition of Access, this automatic shutdown of the running instance does NOT occur. So you can launch the full edition of ACcess and you don't have to provide a open file (makes sense, since you might be a user about to create a database - you cannot do that with runtime UI at all).

    So creating a running instance of Access using com object automation IS NOT POSSIBLE with the runtime. IN fact more specific: The running instance is created – but then it shuts down due to no file name having been provided to open (and as noted createobject has no provisions for providing a valid file name- you have to use create object, and THEN use openfile).

    The only way to get around this runtime limitation is to use the Shell() command to launch the runtime (and that shell command line allows you to pass + provide the file name for Access to open). Once you created the running instance of Access with Shell() command you CAN in fact use GetObjejct in your code to consume and automatic the running instance of Access.

    So to be clear – you cannot in real world practical terms using com object automation and create a "useful" running instance of Access with create object since as noted the instant you do, it shuts down due to not have any open file name passed. If the create object command allowed one to specify a file name, then you could in fact get around this limitation.

    So your only choice here will be to use the Shell() command, and once that running instance of access is up and running (and you proved that mdb/accdb file with that shell command). Then you should be able to grab that running instance using GetObject in place of createObject.

    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada


    Tuesday, August 14, 2012 3:53 PM

All replies

  • Sounds like a references issue to me.

    On your dev machine, add a routine that loops over the References collection, outputting the Guid property along with the FullPath, and compare the guids to the one in the error message.


    -Tom. Microsoft Access MVP

    Tuesday, August 14, 2012 1:22 PM
  • You cannot create an automated instance of the Access runtime.

    In fact to be more precise, the VERY important issue is this:

    If you open a copy of the runtime without passing a mdb/accdb file to open on the command line, the instance of Access starts up, and then:

    I don't have an open file – I will shut down

    (re-read the above over again – then read above again).

    What this means is that in fact you can create a running instance of the runtime, but the instant it is created and loaded – it THEN ALSO shuts down right away since no file name was passed on the command line. In fact this design is to thus allow/prevent stray instances of msacccess.exe running since if a user clicked on the runtime, they would have NO WAY to shut down that instance (the UI for the most part is hidden and not provided).

    What this means is you need to provide a valid file name when launching the access runtime.

    PROBLEM:
    You cannot provide a value file name when using create object. So the create object works, but then Access runtime says:

    Hey, no file open – I will shut down.

    In the FULL edition of Access, this automatic shutdown of the running instance does NOT occur. So you can launch the full edition of ACcess and you don't have to provide a open file (makes sense, since you might be a user about to create a database - you cannot do that with runtime UI at all).

    So creating a running instance of Access using com object automation IS NOT POSSIBLE with the runtime. IN fact more specific: The running instance is created – but then it shuts down due to no file name having been provided to open (and as noted createobject has no provisions for providing a valid file name- you have to use create object, and THEN use openfile).

    The only way to get around this runtime limitation is to use the Shell() command to launch the runtime (and that shell command line allows you to pass + provide the file name for Access to open). Once you created the running instance of Access with Shell() command you CAN in fact use GetObjejct in your code to consume and automatic the running instance of Access.

    So to be clear – you cannot in real world practical terms using com object automation and create a "useful" running instance of Access with create object since as noted the instant you do, it shuts down due to not have any open file name passed. If the create object command allowed one to specify a file name, then you could in fact get around this limitation.

    So your only choice here will be to use the Shell() command, and once that running instance of access is up and running (and you proved that mdb/accdb file with that shell command). Then you should be able to grab that running instance using GetObject in place of createObject.

    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada


    Tuesday, August 14, 2012 3:53 PM