none
Access 2019 not shutting down properly RRS feed

  • Question

  • My database contains only VBA modules.
    I compile everything. 
    Run everything.
    Save everything. 
    Shut down Access.
    Access closes, but does NOT delete the lock file.
    Attempts to delete the lock file with Windows Explorer doesn’t work.
    If I shut down, or restart, the lock file is gone when the system restarts.

    I create a simple database one table, one column.
    No modules.
    Save everything. 
    Shut down Access.
    Access closes, DOES delete the lock file .

    OS Name Microsoft Windows 10 Home
    Version 10.0.18362 Build 18362



    peter n roth - http://PNR1.com, Maybe some useful stuff

    Thursday, August 22, 2019 4:12 AM

Answers

  • Peter - It's always been best practice to set objects to nothing when done with them. Access used to clear pointers for you but it appears it isn't doing that. Actually, I find that an improvement. Access VBA has always compiled sloppy code. Not using Option Explicit is a good example of that sloppiness.

    Bill Mosca
    www.thatlldoit.com
    http://tech.groups.yahoo.com/group/MS_Access_Professionals

    • Marked as answer by Peter N Roth Thursday, August 22, 2019 6:36 PM
    Thursday, August 22, 2019 6:24 PM

All replies

  • Hi Peter,

    Just a guess, what about something that might still link to your Front-End database?

    Thursday, August 22, 2019 5:16 AM
  • Access closes, but does NOT delete the lock file.

    Hi Peter,

    I can share my experiences with not properly closing of Access. It is not A2019 specific, since I still use A2003.

    All my applications share the same linked code library, with almost all functionality for any application, including a form/subform combination to make dynamical forms.

    In the user application I use modules to tune the form/subform to make the form specific for its momentary task.

    When I declare objects as global variables on module level in the user interface (and use such a variable), and I close the application, then Access closes, but a backgroundprocess with Access keeps running. I can re-open the same application without a problem, but running a different application gives problems. When I close the background process, I can continue in the normal way. Declaring objects within procedures give no problem, even without closing these obejects and setting them to Nothing.

    In my shared code database I use this technique also many times for dynamical forms that are shared over all applications. Here I can declare and use as many global objects as I want, without any problem.

    My solution of course is not to use objects as global variables within user interfaces, but a number or a string as global variable, to declare the objects within the procedures.

    Perhaps this gives you a clue to understand your problem.

    Imb.

    Thursday, August 22, 2019 8:07 AM
  • Probably some method opens an object and doesn't close it...so the lock remains open..

    Just import the forms step by step to see where it causes this lock.

    Thursday, August 22, 2019 9:38 AM
  • Peter - I've had this happen to me for no reason. I always close objects and set them to nothing, but sometimes Access hangs after closing. I find that rebooting my machine fixes that problem.

    Bill Mosca
    www.thatlldoit.com
    http://tech.groups.yahoo.com/group/MS_Access_Professionals

    Thursday, August 22, 2019 3:22 PM
  • Guys –

    Some of you are not reading line 1 of my post.

    There are no Forms, no back end, no shared library.

    Also, no global variables. I'm doing some experiments, trying to keep everything simple.

    I have 3 Subs each containing an iteration over a Collection.

    Per suggestions by TsGiannis and Bill Mosca, I have set the loop variable (a local obj) to Nothing at the end of each of the loops. Access now closes properly.

    This seems to indicate that VBA doesn’t collect garbage at the end of Subs and Functions the way it used to   ?


    peter n roth - http://PNR1.com, Maybe some useful stuff

    Thursday, August 22, 2019 6:07 PM
  • Peter - It's always been best practice to set objects to nothing when done with them. Access used to clear pointers for you but it appears it isn't doing that. Actually, I find that an improvement. Access VBA has always compiled sloppy code. Not using Option Explicit is a good example of that sloppiness.

    Bill Mosca
    www.thatlldoit.com
    http://tech.groups.yahoo.com/group/MS_Access_Professionals

    • Marked as answer by Peter N Roth Thursday, August 22, 2019 6:36 PM
    Thursday, August 22, 2019 6:24 PM
  • That’ll be my new default of objects myself.

    And it seems to me most reasonable that Option Explicit would be enforced whether declared or not.


    peter n roth - http://PNR1.com, Maybe some useful stuff

    Thursday, August 22, 2019 6:37 PM
  • There are a lot of languages that don't force you to declare variables. They just come to life when the line is executed. One little typo and it takes you hours to debug.

    Bill Mosca
    www.thatlldoit.com
    http://tech.groups.yahoo.com/group/MS_Access_Professionals

    Friday, August 23, 2019 9:22 PM
  • Thanks be to God I’ve grown into avoiding all of them, by choice and design.

    Fortran, when it was spelled FORTRAN, was one of the ones you mention. Fortunately, I learned to read octal dumps (really!) – well, we had to.

    Then along came Niklaus Wirth’s Pascal, the error behavior of which was every variable in every routine: named, with their values, printed out.

    All on Control Data computers. Great fun! Thanks for kindling the memory!


    peter n roth - http://PNR1.com, Maybe some useful stuff

    Saturday, August 24, 2019 12:31 AM
  • It's always been best practice to set objects to nothing when done with them.

    Hi Bill,

    This is part of an endless discussion.

    I still keep wondering why the rest of the world benifits from your good advices, while I can "ignore" them without any problems. Is this because I still use A2003, or because my housestyle of programming is different?

    Well, your answer will be: "it does not harm", but that is different form the understanding why most(?) of the developpers need to take this action, and others (me) not.

    Imb.

    Saturday, August 24, 2019 6:43 AM
  • Sticking with A03 may be one reason, Imb.

    What OS are you using? A recent W10 update broke some VB6 and VBA code.

    Better would be a reliable garbage collector such as C# supplies.


    peter n roth - http://PNR1.com, Maybe some useful stuff

    Saturday, August 24, 2019 3:33 PM
  • What OS are you using? A recent W10 update broke some VB6 and VBA code.

    Hi Peter,

    OS: Windows 10, versie 1903.

    All my code is compiled in A2003. The end users use A2003 up to A2016. Is it the compiled code or the running of the compiled code that would give the problem?

    One application still runs in A2003 on Windows7. This computer is too old to install A2007, or change to Windows10.

    Imb.

    Saturday, August 24, 2019 5:47 PM
  • The compiled code relies on a system DLL that was changed in an update. It had to do with passing an empty Param argument to a function. If the code had one of those, running it caused a crash.


    peter n roth - http://PNR1.com, Maybe some useful stuff

    Saturday, August 24, 2019 8:32 PM
  • Imb - I'd say 2003 is the reason. That was my favorite version. It was the most stable and the most reliable and the most forgivable...which led to some mighty sloppy coding practices by some developers.

    That said, if you have been successful in the past it does not mean things will not change. From reading almost all of your posts in this forum you continually impress me as one of the most skilled Access developers I know. But operating systems are evolving constantly. There may come a time when no one has 32-bit OS and you will have to commit to evolving as well, even if it means just cleaning up your pointers explicitly. [smile].


    Bill Mosca
    www.thatlldoit.com
    http://tech.groups.yahoo.com/group/MS_Access_Professionals

    Monday, August 26, 2019 2:48 PM
  • That said, if you have been successful in the past it does not mean things will not change.

    Hi Bill,

    Thank you for your nice words.

    I fully realize that things will change, and I have to change with these changes. On this moment I develop in to "lowest" Access version, and almost ready to go to A2007. But above all, I want to "understand" the things I am doing. Adapting the applications to a "higher" level would not be too difficult, as all functionality is generalized and only needs to be adjusted in these routines.

    But, I am not that skilled Access developper. There are many far better developpers in this forum, who also teach how to use Access as it was intended. I hardly use any default Access functionality. You better call me one of the weirdest Access developpers, resulting in fast development and optimum user flexibilty.

    Imb.

    Monday, August 26, 2019 8:22 PM
  • Imb - I strongly suggest you skip 2007. It has new features that were dropped in 2010 and was one of the versions that had some very nasty bugs like the one the erased the VBA project from a database without warning. That bug was eventually fixed with an update, but not everyone keeps their Office products updated.

    2010 is much more reliable and is almost as easy to use as 2003 (with the exception of custom Ribbons, a pain in my neck).


    Bill Mosca
    www.thatlldoit.com
    http://tech.groups.yahoo.com/group/MS_Access_Professionals

    Tuesday, August 27, 2019 4:52 PM
  • I strongly suggest you skip 2007.

    Hi Bill,

    Thank you for your advice, I hardly can ignore that.

    But unfortunately! I develop my applications on a non-commercial base. My "customers" are small scale "organizations" that have not the budget to buy commercial applications. Most of them run A2007.

    I do not know what the new features are in A2007 that were dropped again, but I don't care about that. As I am happy with the A2003 features an my own added functionality.

    A lucky factor is that I do not use any Ribbon at all. In any application on any form the user can click a Task-button (or click the form's backgroud) to open a dynamical form with all possible functionality that is allowed in that context and according to the authorization level.

    Another factor is that the users never (need to) go to any development mode. All needed flexibility is build in in the linked library. I am trying to make applications, where users almost intuitively know what they must do. It is hard to realize this, but there is progress.

    As an example, the very last A2003 application is an application around movie pictures, totally managed by my youngest son, a mentally disabled man, functioning on mental level of 5 à 6 years. He succeeded to gather almost 25,000 movies including titel, directors, players, locations, rating, etc., and for most movies a reference to the IMDB.

    Imb.

    Tuesday, August 27, 2019 6:02 PM
  • If I had the choice, I would skip 2007 as well and work with 2010 or 2013.  As per the usual, Bill's right, again!

    And between 2003 and 2007, 2003 hands down!


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

    Tuesday, August 27, 2019 6:24 PM