none
DB ACCESS CERATED WIHT WINDOWS 10 + OFFICE 16 NOT RUNNING UNDER WINDOWS 8.2 + ACCESS RUNTIME 2016 RRS feed

  • Question

  • Hello,

    I'm developing an Access db with office 2016 on my PC  (with installed windows 10).

    I have to distribute it to all other PC that are running Windows 8.1.

    These PCs have installed different version of Office (typically 2013) but all without Access.

    So I'm installing Access runtime 2016 version (accessruntime_4288-1001_x86_it-it.exe) on these PCs.

    In a form of the DB I use a Treeview control form mscomctllib in order to use Dran&Drop events to record info (filename, path etc.) of dropped file.

    If DB version is 2000 there are non problems (but i cannot create an MDE version of the DB with MS ACCESS 2016, I have to save it in a newer version)

    If DB version is 2003 or 2016 the treeview control generate an error on all its events (MouseOver, Click, DragOver etc etc)

    This happens using normal MDB or ACCDB.

    If I try to use MDE or ACCDE compiled version of the DB I have an error opening the DB the says that the version of the DB is newer than the Access version on the PC (but I can open the MDB or ACCDB so Access runtime its working)

    I have found somewhere on the net that there is an Office issue with MDE or ACCDE files so I installed all updates but still with non success. I tested this on 2 different PCs with Windows 8.1 but with the same result.

    I think that the problems are 2:

    1) to run the newer version of the DB (in MDB or ACCDB version) without error on the mscomctllib treeview control

    (maybe this issue is due to different mscomctllib version in the OS, but it is strange because it works with DB in 2000 MDB version)

    2) to run the MDE or ACCDE version of the file on windows 8.1

    Any help is very much appreciated

    Thanks

    Massimo

    Monday, September 24, 2018 8:30 AM

All replies

  • Hi Massimo,

    I notice your issue is related to Access app. To better fix the issue, I would move the thread to Access forum for more discussion.

    Thanks for your understanding.


    Best Regards,
    Winnie Liang


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Tuesday, September 25, 2018 9:00 AM
  • I could be wrong but I think you are facing the typical versioning issues.  Your local dev build is probably more recent than that of runtime, and headaches incur.  You need to do all your development in the oldest version that will be used to run your database.

    There have been issues with ActiveX controls in the past, exepecially the treeview, so they are to be avoided!  You may like to look over http://www.devhut.net/2017/06/15/great-access-tools-treeview-control/ for more info on the subject.


    Daniel Pineault, 2010-2018 Microsoft MVP
    Professional Support: http://www.cardaconsultants.com
    MS Access Tips and Code Samples: http://www.devhut.net

    Tuesday, September 25, 2018 12:31 PM
  • Thank you Daniel,

    Yes, I think so that is a versioning issue, but I would like to know why it happens only with MDE or ACCDE and not with MDB or ACCDB that are opened with no error. Also I know that with build 1710 this issue has been solved, but there is no way (or better I have not found it) to upgrade the MS downloaded runtime version of Access 2016 to this (or newer) build.

    Thanks for the suggested Treeview, I wil check its Drag&Drop events.

    Wednesday, September 26, 2018 10:07 AM
  • What occurs is that access will detect a “difference” and re-compile the VBA code on the fly.

    However, with a compiled version of your application, and all of the VBA source code stripped out (mde, or accDE), then this re-compile for the different version(s) or even different update levels cannot occur.

    This is why the non-compiled version works on those machines.

    The “normal” solution is of course to re-download and re-install the runtime. (New updates are included in the runtime, but the “big” issue and problem when “when” such updates occur.

    As a general rule thus.

    You really want to develop with a version of Access with update turned off. You can disable the updates to office, and still for example keep windows update active.

    And these auto updates don’t update the runtime, so this way you can hold off until such time you are sure that the runtime has been updated. Once the runtime has been updated, then it can (has) to be re-installed.

    So realistically, the only real way to solve this is to disable your updates to office. You could I suppose deploy an accDB. While this might fix errors, it has two BIG ISSUES:

    #1:
    Any un-handled error will re-set all your VBA vars – this makes such applications far less reliable.

    #2
    Any un-handled error with the runtime not only re-sets variables, but THEN after the message, the runtime will shut down!

    If you distribute an mde/accDE, then NEITHER of above occurs (runtime errors don’t re-set VBA nor does runtime errors shutdown the application either).

    Given the above two really nice advantages of an accDE over that of accDB, then I always as a rule distribute an accDE for this reason. (And of course it prevents users from messing around with the application).

    So the only approach I can suggest here is to turn off updates to your Access/office. Once done, then you should be just fine, since as noted windows updates do NOT update the access runtime.

    That way your development version used to compile the accDE will never change on your computer, nor will the runtime on those target computers.

    Over time if you decide to move to a later version, when then you have to check + insure that the runtime ALSO been updated. If yes, then you have to re-install the runtime on each of those machines, and then update your access version.

    I find that just disabling the updates, I get several years if not more of trouble free deploys. As long as users don’t download and re-install the runtime, and you don’t update, then everything is fine.

    However, if you let the IT department to download the runtime as required (say for a new computer or re-build), then things will break. As a result I suggest they download a runtime copy and use that for future installs and setups. That way, again you are good to go in the case of new computers or re-builds occurring.


    Regards,
    Albert D. Kallal (Access MVP, 2003-2017)
    Edmonton, Alberta Canada



    Thursday, September 27, 2018 2:11 AM