topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • July 23, 2019, 02:38 PM
  • Proudly celebrating 13 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Last post Author Topic: CLIPBOARD HELP+SPELL LATEST VERSION INFO THREAD - v2.45.0 - Apr 28, 2019  (Read 264286 times)

IainB

  • Supporting Member
  • Joined in 2008
  • **
  • Posts: 7,418
  • Slartibartfarst
    • View Profile
    • Read more about this member.
    • Donate to Member
@Mouser:
Iain can you point me to the thread about that so I can refresh my memory?

Sure, here you go:

@mouser: Nope, the gotcha is still there after boot-up has completed with R:\Temp running OK.
As soon as CHS is restarted after setting the CHS Tweaks to Force to system Temp directory, the error:
   Error DBG103: DBISAM Engine Error # 11013 Access denied to table or backup file '124120'
 - pops up and and CHS is without any settings.
Whilst CHS is still thus active, I go into CHS to change the Tweaks, and this error pops up again:
   Error DBG103: DBISAM Engine Error # 11013 Access denied to table or backup file '124120'

I then set CHS Tweaks back to Let database engine decide and then terminate CHS and restart it. CHS then seems to start up just fine, with all settings correct as previously.
This seems to be consistently repeatable.

However, CHS is definitely "allergic" to the ImDisk RAMdisk under this current version of Win10-64 Home, whereas it was perfectly OK using that RAMdisk under Win10-64 Pro.
I presume that the likely cause could be some vestigial Registry entry in this Home version which remains even after fast startup has been disabled. I shall try to research that as I'd like to know.
It might be worth identifying exactly what CHS looks at when the user sets CHS Tweaks to Force to system Temp directory, as a good starting-point, because that's when the error is triggered - e.g., whether it checks the Registry for anything at that point.

As far as any other apps being similarly afflicted by this mysterious error, so far there's still been no sign. Pretty much everything that has to use system Temp will need to be happily using that ImDisk RAMdisk. Apart from CHS, everything else seems stable with it, so far.    :o

That's very odd.. I wonder if maybe CHS is getting the wrong directory information somehow and trying to write somewhere it shouldn't.
Maybe I can have it report where it really is trying to write.
AND at the lease I can have it try to give a better error about the likely source of trouble so people less rigorous than you have a chance at fixing the problem. 

^^ Yes, those could be useful ideas. Thanks.

By the way, I just had an installer automatically run itself from the RAMdisk Temp and it kept failing, but it ran OK from a directory on C: drive.
I recall this problem (installers failing when run from R:\Temp) being a problem sometimes, with some installers, so it's probably nothing new. I never could figure out the cause of that.

I just realised that CHS writes the file CHSDatabaseLockFile.lck to the ImDisk RAMdisk (R:\TEMP) without any apparent problem, so it's not totally "allergic" to the R:\TEMP directory.
Don't know if that helps any, but I thought I should mention it anyway.

« Last Edit: May 09, 2019, 10:13 AM by IainB »