SQLite Forum

cannot create tables in sqlitestudio than other apps can see
> using a different table in ...appdata... although it says it is reading it fro "C:\newff"

It's fun when a completely unrelated problem in a different software, or hardware/OS errors on the machine, makes you think your software is broken.

In case you are interested, this is why the first replies to your problem statement started suggesting the UAC virtualization might be the culprit.

TLDR:UAC+Old Software does this --------

Long ago in Windows and its historic unsafe file systems, software (and virii) had the unsafe ability to write anywhere in the system. Windows attempted to fix this by preventing software, or making them ask permission, to write to any place deemed "unsafe".

Problem is this would break a lot of legacy software, so Windows added the "helpful" UAC virtualization that, if you (as the older software) try to write to a place deemed unsafe and you did not ask to do so (Elevate) or state your intents in the Windows executable manifests, it would take the file you are trying to write, say "c:\securefolder\myfile.txt" and internally redirect (soft-link) it to a "safe" space over in the user's own /AppData folder.

As you can imagine, older programs (like the one you've used) that did not adapt to play nice with the manifests and UAC requirements, would fall prey to this problem. To add insult to injury, a user could simply turn the UAC off, and then everything would work again, but there was no way for software to know whether a file it was accessing was being virtualized or not. 

The amount of confusion this "magic" caused is hard to measure, but I can confirm it is measured in blood and tears - you being the latest victim.


As to your problem, it does sadly seem something is amiss on that computer, because the things you are trying to do should work fine, as you noted, and indeed it does on other places, as you also noted, and Windows 7 already had UAC, so that's not the difference. You are also correct in that the hostname is of no consequence in that DB object.

Is there any sort of drive-encryption or file-encryption software active on any of the computers?  We've also seen antivirus software preventing write access while it is checking on a file. Either way, this seems a system-related problem.

Good luck!