Clipboard Help+Spell errors

[imscottb]

Hello,

I have been having problems recently with Clipboard Help+Spell, I think.
When I start my computer (Win7 x64)  I get many error boxes saying like the following and looks like the  attached image.
Error DB65: DBISAM Engine Error #11013 Access denied to table or backup file 'Clip Table'

Error EX31: Operation aborted


Error EX29: Operation aborted



Error EX31: Operation aborted

Erro EX59: Table Clips: Cannot modify a read-only dataset


PLEASE any help as to how to clear this up.
I have uninstalled and then reinstalled the product, but NO help.

Thanks, so much.
Scott

[mouser]

It sounds like it's not able to save it's database file.

Did you by any chance migrate this installation from one computer to another -- in other words manually copy files instead of using the installer, or use the portable version?
Or maybe install it into a non-standard directory?  Or do you have a network location for your documents?

[imscottb]

Yes, I did migrate this installation from another computer. After reading this, what  I did was uninstall once again, delete the OLD profile folders and am now reinstalling.
Hope this will take care of it all.
Thanks, bunches.

[mouser]

what may be happening is you may have a ConfigDir.ini file in the C:\Program Files x86\ClipboardHelpAndSpell directory which is telling it to save its files where it shouldn't/can't.
the solution is just to delete the ConfigDir.ini file and it will then default to a MyDocuments subdirectory.

You can move over your old database and settings, they just need to be under your MyDocuments directory where CHS can access and modify them.

[imscottb]

Mouser, thanks for the tip. WHERE in the My Documents folder should the ConfigDir.ini file be placed? I have a folder for CHS. Should it be put in that folder or in one of its sub folders?
Thanks, so much.
YES, the file was in the Program Filesx86\ folder. UGGH.
Thanks so much. I am really trying to figure this out now.

Merry CHRISTmas.

Scott

[mouser]

The ConfigDir.ini file should be wherever the ClipboardHelpAndSpell.exe executable is.

[imscottb]

Mouser,
thanks for the reply.
Should the ClipboardHelpAndSpell_UserTools.ini file also be in the same location ... in the Program Files folder, or wherever the program is installed in?
For some reason, all of a sudden I am getting errors again -- pop-up's that I haven't had in a couple of weeks.
Thanks, so very MUCH.
Scott

[mouser]

user tools should be with your settings and database, all in your CHS documents folder.

[imscottb]

Thanks, that's where it is.

[imscottb]

I am getting a LOT of new error pop ups and have no idea why.
started all of a sudden the other day.
trying to figure this out.
Thanks, so much.

[Ath]

Maybe your AV is acting up, or had a bad update, you could try excluding the CHS directory from it.

[imscottb]

That did it. For now. Thanks, so much.

[IainB]

Having migrated/copied across to another PC, CHS is getting the error:
---------------------------
Error..
---------------------------
Error DBG103: DBISAM Engine Error # 11013 Access denied to table or backup file '356120'
---------------------------
OK 
---------------------------
The backup file number varies from try to try, but the DBISAM error remains the same.

Any relevant ConfigDir.ini files have:
  PORTABLE=TRUE
  CONFIGDIR = .

[Ath]

You have removed any read/only attributes from your files?

[Shades]

Did you place it like:
  C:\(your.portable.CHS.instance)
or
  D:\(your.portable.CHS.instance)

In other words, the root folder on any of the partitions of the computer?

If so, Windows tries to protect you from yourself. It is better to create a folder structure like: C:\Portable\(your.portable.CHS.instance) and adjust the security rights of folder: C:\Portable (and its sub folders) by yourself. However, if you have a different partition than C:\ I would use that partition to create for example: D:\Portable\(your.portable.CHS.instance)

Windows gives you much less grief in any other partition than C:\ regarding file/folder access rights.

[IainB]

@Ath + @Shades: Thanks for trying to help.

The files (in the CHS database) in question are definitely unticked in the Read-only attribute. I have double-checked this, as I initially thought that would probably be the problem, even going so far as to enforce them to be unticked again. It made no difference though.

The files are in a directory on the C:\  drive, which is where they have always been since I started using CHS. The drive location has never been a problem before, anyway, so I don't see how/why it could be a problem now. It doesn't seem to be a problem, at any rate.

[Shades]

While the 'Properties' screen of a file shows the attributes set for that file, that is not necessarily the way how that file is treated in day-to-day use. There is a tool SetACL Studio, (the company gives away a full license for that tool) that shows you how the access right for any file or folder are really managed by Windows. It also allows you to make adjustments and it is a much nicer interface than the default tools that Microsoft delivers with Windows.

It might be an update of Windows 10 that adjusted/resetted the ACL (Access Control List) for files/folders on your C:\ partition.

[mouser]

Having migrated/copied across to another PC, CHS is getting the error:

this does sound like a problem where you might have CHS running from (or trying to save to) a directory that it does NOT want to allow access to, assuming you are using portable=true.

a good first thing to try would be to move it to another directory where your user files are and see if you have the same problem.

yet another thing to check is the "Backup/Maintenance" tab, and look where it says "Directory where backups should be stored" and the line under that where it tells you the ACTUAL DIRECTORY it is trying to use to store backups -- make sure that is a directory that an app can write to.

And also the "Tweaks" tab, look for "Temporary DB file location" and try changing that.

If these still fail, let us know the full directory where you are running CHS from.

[IainB]

@mouser: Thanks for your comment. I put my Sherlock Holmes hat on and went through the checks you suggested to verify what directories are being accessed/written to, and have now figured out and fixed the problem and discovered what seems to be a quirk in CHS. It's quite interesting:

1. Context: I have migrated CHS from a laptop with an oldish version of Win10-64 Pro to another laptop with a more up-to-date version of Win10-64 Home.
   Problem: CHS consistently fails with the DBISAM error above and all previous settings are lost.
   
2. CHS directory:
   My user ID is the Owner of the FARR directory and subdirectories at:
         C:\UTIL\Windows utilities\FindAndRunRobot\
   These directories are all unchecked for Read-only.
   The location of CHS is in the plugins folder of FARR:
         C:\UTIL\Windows utilities\FindAndRunRobot\Plugins\Clipboard Help+Spell\
   
3. CHS Database:
   The CHS Database path is:
         C:\UTIL\Windows utilities\FindAndRunRobot\Plugins\Clipboard Help+Spell\Database\
   
4. CHS Backups:
   The CHS Backups path is:
         C:\UTIL\Windows utilities\FindAndRunRobot\Plugins\Clipboard Help+Spell\Backups\
   
5. CHS Tweaks: Is set to Force to system Temp directory - for potentially fastest response time.
   NB: System Temp is ImDisk, a dynamically variable-sized RAMdisk (up to 2GB) - in R:\Temp and which is set as the system default Temp/TMP directory.
   Changing CHS Tweaks to either:
           Let database engine decide, or
           Use Database "Temp" subdirectory
   - fixes the problem and all the previous settings are restored OK.
   
6. The reason for this is explained by a warning in the ImDisk configuration tool:
   

   ImDisk Warning: the fast startup feature of Windows is enabled. This can lead to some issues:   • The system writes the ramdisk content onto the hard drive     at shutdown, and restores it at startup.   • The data synchronization feature of ImDisk Toolkit does not     work at system shutdown. Open the Shutdown settings to disable the fast startup. (Button) Shutdown settings (Checkbox) Do not t show this warning again                            (Button) Close

   Obviously, I want to keep the R:\Temp RAMdrive working, as it speeds up the the system, so I disabled fast startup.
   
7. Gotcha in this version of Win10?:
   The fast startup shutdown settings are greyed out (cannot be changed), but you can change them, except that it is sorta hidden on another page (I did a duckgo search to find that out). After disabling the fast start settings, the ImDisk configuration tool no longer gives the warning message. However, CHS still would not work with the R:\Temp setting, so I left the CHS Tweak set at Let database engine decide, (which works OK) - and the RAMdisk seems to work fine for all other applications (so far). Not sure whether CHS using the CHS Temp folder instead of the RAMdrive will slow CHS response times on some large database searches, but we shall see. However, it seems as though CHS is sensitive to the RAMdrive and doesn't like to use it, though it apparently worked OK on the previous laptop (with the older Win10-64 Pro). I would like CHS to use it, for optimum response, so that could be a something needing a workaround/fix, if/when you have the time to investigate, please. 

Thanks again.
CHS remains one of my daily most useful PIM tools and I was nearly overcome with despair when it wouldn't seem to work.

[mouser]

That's a fascinating discovery -- thanks for reporting it!
Following up, here's what I'd like to know the answer to: If you change back to the "system temp" directory that causes the error, but manually restart CHS after it has booted, does the error disapear?
If so, and the problem is only that at early BOOT time the system temp directory causes trouble, another solution would be to have CHS start up late in the boot process (by using a 3rd party tool for that or otherwise doing it), instead of having CHS do its own operation to start at bootup time.

Having said that, I would worry that if CHS is having this error trying to reach the system temp drive, maybe other apps could too -- but in a way that might not be so obvious..

[IainB]

@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.   

[mouser]

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. 

[IainB]

^^ 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.

[IainB]

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.