Corrupt database
Corruption used to be a major problem when LabManager was implemented on a physical file server network. Now that it is on a virtual network it has become only an occasional problem.
The advice then was to attempt an automated repair. The instructions would be a 'walk through' that repair process. Sometimes it worked ok but usually the Access engine 'fixed' itself by just deleting the records it couldn't repair. That was the wrong thing to do for our users and so a different method was found.
Nowadays a separate background process takes a copy of the database every ten minutes, so if corruption does happen, then the last good copy can replace the 'live' database and work can continue but any data entered since that copy would now need to be re-entered.
This is how to do it:
But first check that it is not a false alarm Nine out of ten cases are!
(.........
Occasionally, if the server is very slow or if an intensive processing section in LabManager is running and if the background process starts to make an interim backup all at the same time, then this background process may interpret the slow (ie lack of response in the time allotted) as the behaviour of a corrupt database. In this case it will mark it as corrupt, falsely!
An intelligent user would see that the time stamp on the interim backup was the same as the time on the LabManager database, they would also see that the database size has not been reduced. The progression in size of the interim backups is always either the same as previous, or larger, depending on usage.
If the user is confident that it is a false alarm then the corruption 'flag' can be removed so that the database is available for use again.
To do this open the text file called 'LabManager.ncl' remove the word 'corrupt' from the line 'LogoutYN=corrupt'. If the word 'corrupt' is not there then this is not the cause of the problem so abandon this and proceed to the next section. If it is then close and save the text file.
Start LabManager again, assure yourself that is is ok, perform a backup using the 'system' toolbar option. Check the size of the database compared to previous interim backups, it should be the same or slightly larger. If this works ok then it is good to go.
..........)
Otherwise;
On any computer open two Microsoft Explorer Windows on your desktop.
One at "S:\LabManager\LabManServ"
One at “S:\LabManager\LabManServ\Backup\IntrmBU”
The database file is called “LabManager.mdb”. In some views the “.mdb” is hidden, be careful not to confuse the database file with other files such as “LabManager.ldb” or “LabManager.ncl” or “LabManagerMess.mdb”. The database file is always much larger than the others e.g.
27,000 KB or more compared with less than 1000 KB. Be careful though because a bad corruption may also reduce the size of the database massively.
In “S:\LabManager\LabManServ\Backup\IntrmBU” arrange the files in time descending order so that the most recent is on the top. You will see files like “LabManager-n.mdb” where n is a number representing the number of interim backups made that day. The idea is to identify the most recent backup. It will be the one with the largest number (n) and is therefore the most recent. Choose the one that you are sure is earlier than when the database became corrupted. Corruption is sometimes obvious to one or another user in that the behaviour of LabManager becomes erratic.
Do not choose one if it is only a couple of minutes old!
Copy your chosen file into the “S:\LabManager\LabManServ” folder. Copy the file don't move it otherwise the numbering sequence will be altered.
Remove the database file “LabManager.mdb” from this folder to say “tempfolder” for later investigation.
Then rename the file just copied from “LabManager-n.mdb” to “LabManager.mdb”.
Now open the LabManager
application if it opens normally then that is all that is required, just check the most recent entries or edits and bring the database back completely up to date. You may see a warning that the database is being backed up by yourself or another user with a time and date. If you are happy that that backup is not actually proceeding then you may select the 'Retry' option. That will reset the internal parameters that permit a backup to proceed
If this replacement database is also corrupted, then repeat the copy and replace operation using an earlier backup file.
You may find a log of entries and edits etc in the temporary log files. Navigate Explorer to “J:\LabManager\DebugLog” the relevant files in this folder are named to include the date as follows:
“ResultsLog180221.ncl”. A log of the results entered for 21/02/2018
“InputLog180221.ncl” and “JobSummary180221.ncl”. A log of the Jobs entered or modified for 21/02/2018
These two files should be opened with “Notepad” and will prove helpful in re-entering any missing data.
Should the ‘Message.mdb’ database become corrupted then follow the same procedure as above but using the database names “LabManagerMess.mdb” etc.
Do not delete any files just copy or rename them, in case of mistakes.