|
JCapper Message Board
|
|
By |
Bug Fix – Database Locked Error |
jeff 8/10/2012 6:04:34 PM | Bug Fix – Database Locked Error The Main Module introduced in the 08/06/2012 Platinum and 08/07/2012 Silver new program updates uses more memory than previous versions of the Main Module. Using more memory means Calc Races routines that are more likely to slow Windows’ ability to clear the .ldb lock file placed on the JCapper2.mdb file during the repeated read/writes to the tables in that file during a Calc Races. In turn, that means increased instances of encountering a database locked condition. A few of you have reported database locked errors without the standard message box offering a viable recovery path. (Not my intent.)
Main Module Special Download Package This download package will get you a Main Module that contains a bug fix for the database locked condition. The bug fix provides additional places in the Main Module where “traps” exist for the database locked condition – and whenever a database locked condition is encountered - logic in the bug fix is there to provide the user with a recovery path so that the Calc Races routine can be executed to completion.
Install Instructions are available in the Release Notes -click here- and a Main Module Only download package link is now available on both the Platinum and Silver new program updates downloads page.
-jp
.
| jeff 9/1/2012 3:26:29 PM | Special Download Package (Main Module Only) August 31, 2012
Main Module – Improved Handling of Calc Races Database Locked Condition
Background Info - Why does the database locked condition occur? From what I can see on the machines I am using, and from what I have been able to determine by reading about how Windows handles multiple apps running at the same time:
Whenever a machine runs low on memory it halts execution of apps running in open program windows. (This includes apps running in the background not launched by the user - or even without the user being aware they are running.)
Once everything has been halted, Windows then writes everything in memory to the swap or paging file, clears everything in memory, and then reloads everything in the swap or paging file back into memory - and only then - begins running apps again.
This process can take several minutes. And depending on what is running in the background and how much memory the apps running are (collectively) using can sometimes cause a machine to wind up in a state where the machine is constantly halting program execution so that the machine can continually go through the exercise of writing to and reading from the swap file.
During a Calc Races routine, logic in the Calc Races routine itself performs hundreds of read/write operations to the tables in the c:\JCapper\Exe\JCapper2.mdb file. Windows has a mechanism for securing .mdb database files. When a program is actively engaged in the act of reading data from or writing data to an .mdb database file, Windows “locks” the file so that other apps (and/or users) can’t write to that file while it’s in use. The mechanism for doing this is to put a “lock” file on the same folder as the .mdb file. Lock files have the same file name as the .mdb file except for the file extension. The file extension for a lock file are the characters “.ldb” (without the quotes.) If you were to sit and watch the c:\JCapper\Exe folder during a SQL Calc Races, you would see a file named JCapper2.ldb (that’s the lock file) placed on the folder whenever the Main Module is reading from or writing to the JCapper2.mdb file. You would also see the JCapper2.ldb lock file cleared (deleted) from the folder each time the Main Module isn’t actively engaged in reading data from or writing to the JCapper2.mdb file.
The database locked condition comes into play when a machine runs out of memory during a Calc Races and has to start writing to the swap file. Under those circumstances, Windows is slow to clear the lock file. When the JCapper Main Module attempts to read from or write to its own database file – but can’t because Windows hasn’t been able to clear the lock file from the folder – a database locked error message is the result.
Database Locked Handling Description (Old Way) Up until now, the way that I have handled a database locked error inside of the JCapper Main Module was to present the user with a message box displaying a database locked message while at the same time offering the user an “auto recovery” option that when clicked allows the Calc Races routine to be run to completion. What you may not have known is what goes on behind the scenes (on your machine) when that database locked message appears. I created that database locked message box in such a way that the Calc Races routine itself has to stop executing while the message is displayed. This gives Windows the time it needs to “catch up” and clear the lock file. By the time you click the message and select the auto recovery path, the lock file has long been deleted from the folder – enabling the .mdb file to be read from and written to again. That strategy might be clumsy and inelegant. But it works.
Improved Handling of Calc Races Database Locked Condition The Main Module in this program update comes with a new (better) way of handling the database locked condition.
Database Locked Handling Description (New Way) During a Calc Races routine, the JCapper Main Module in this program update handles the presence of an .ldb lock file on the JCapper2.mdb file in the following manner:
1. The Calc Races routine is halted for a few seconds. The folder where the Calc Races is being run is tested for the presence of the lock file. In most cases (on most machines) halting the routine for a few seconds will give Windows the chance to “catch up” and clear the lock file. If testing reveals that the lock has been cleared, program execution of the Calc Races picks up where it left off – without the user ever being made aware (via a “database locked” message) that a database locked condition was encountered.
2. If testing reveals that the lock file is still there, the Calc Races routine is halted for another 2-3 seconds – giving Windows a second chance to “catch up.” The folder where the Calc Races is being run is once again tested for the presence of a lock file. In almost all cases (on most machines) halting the routine a second time for a few seconds gives Windows the time it needs to “catch up” and clear the lock file. The folder is retested, and if testing reveals that the lock has (finally) been cleared, program execution of the Calc Races picks up where it left off – again without the user ever being made aware (with a “database locked” message) that a database locked condition was encountered.
3. However, if at this point testing reveals that the lock file is still there, the assumption is made that Windows needs more than just a second or two – and a “database locked” message is generated – and you will have to click through it and select the auto recovery path to restart the Calc Races so that it can be run all the way to completion.
Install Instructions:
1. Close down all open JCapper program windows, log into the JCapper message board and go to the program downloads page.
2. Save the Main Module Only Special Download Package (published August 31, 2012) - filename: MainModuleOnly08312012.exe to your hard drive. (Hint: c:\JCapperBuild is a good place to save it.)
3. Double click the download package file (filename: MainModuleOnly08312012.exe) to run the extractor. The extractor will copy the .exe file for the new Main Module (and only the Main Module) to your c:\JCapper\Exe folder, overwriting the existing .exe file for the Main Module, and then on most machines, will launch the Main Module.
That’s It!
There’s nothing else to install – and no import routines to be run. After performing the above install you should be able to use the new Main Module to run Calc Races routines in both SQL and PlayList File Modes – and you should find that the number of database locked messages encountered goes down noticeably.
Enjoy,
-jp
.
|
|