Darren Clemons
Well-Known Member
Well, again today, the wonderfully and consistently corrupt genmapsdata.db3 file reared it’s ugly head yet again. Can anyone please explain or tell me why that seems to be unfixable?
We were told (back in September) that “that will be fixed when Linux update comes out soon”.....well, it’s six months later and no Linux update and no fix for the corrupt file.
It is, without a doubt, directly tied to archiving and/or the unpacking of jobs and is only a problem when there are those (in my opinion) useless duplicated coordinate systems made. It seems that when those duplicate systems are made, and then the jobs that were associated with those duplicate systems are archived and then deleted, if you don’t also delete the duplicate coordinate system, THAT is when we get the dreaded “cannot read dB” message.
Once you see that message - you’re screwed. It’s time to get out to windows screen, find where the file is stored, delete it, reboot and hope everything’s back in order. Today was probably the 15th to 20th time I’ve had to do this since last September.
Question one. Am I the only one seeing this this often?
Question two. If I am, then what could I possibly be doing that would cause this?
I am on the release version of Jfield, I always start and use Ky State Plane single zone for all my jobs with epoch 2010.
Does no good to send job archive, I’ve sent a few months ago and the machine won’t even DO an archive on the job once that file is corrupt. Then, once file is deleted and system is rebooted,the job is “normal” again....nothing evident that anything was ever wrong.
I certainly have no clue as to the intricacies of the programming within the LS, as it is unimaginable,but this really seems like something that shouldn’t take SIX months to fix.
From my experiences, stop the creation of duplicate coordinate systems and this problem stops. It has NEVER happened in any of our LS’s when there isn’t multiple duplicated coordinate systems in the list.
We were told (back in September) that “that will be fixed when Linux update comes out soon”.....well, it’s six months later and no Linux update and no fix for the corrupt file.
It is, without a doubt, directly tied to archiving and/or the unpacking of jobs and is only a problem when there are those (in my opinion) useless duplicated coordinate systems made. It seems that when those duplicate systems are made, and then the jobs that were associated with those duplicate systems are archived and then deleted, if you don’t also delete the duplicate coordinate system, THAT is when we get the dreaded “cannot read dB” message.
Once you see that message - you’re screwed. It’s time to get out to windows screen, find where the file is stored, delete it, reboot and hope everything’s back in order. Today was probably the 15th to 20th time I’ve had to do this since last September.
Question one. Am I the only one seeing this this often?
Question two. If I am, then what could I possibly be doing that would cause this?
I am on the release version of Jfield, I always start and use Ky State Plane single zone for all my jobs with epoch 2010.
Does no good to send job archive, I’ve sent a few months ago and the machine won’t even DO an archive on the job once that file is corrupt. Then, once file is deleted and system is rebooted,the job is “normal” again....nothing evident that anything was ever wrong.
I certainly have no clue as to the intricacies of the programming within the LS, as it is unimaginable,but this really seems like something that shouldn’t take SIX months to fix.
From my experiences, stop the creation of duplicate coordinate systems and this problem stops. It has NEVER happened in any of our LS’s when there isn’t multiple duplicated coordinate systems in the list.
