I have designed and built a database in MS Access 2013. There is a back end file on a shared drive and multiple users use a front end located on their individual PCs.
Occasionally, seemingly randomly, the back end will lock out in read only mode, meaning that none of the front ends can update the back end, and when I open the Back End, I get the yellow bar saying:
"READ-ONLY This database has been opened read-only. You can only change data in linked tables. To make design changes, save a copy of the database".
It won't let you save a copy of the database by the way. Other databases in the same location open correctly.
I have some spreadsheets that access the database read only, occasionally these change to Share Deny Write, and when they do you get the 1kb lock file for the database. This allows me to see who has it locked out. In my case, this file doesn't appear until I open the database read only and then it shows as locked out to me.
Eventually, it tends to just fix itself, but it can take hours and I have no idea what happened to fix it!
I've searched Google and tried everything that's been suggested, and of course restarted my PC a couple of time, none of which fixed it. However, last time this happen, after restating my PC it worked again, could have been a coincidence.
Any advise about how I can see who's locked it, or how I can get it to unlock would be greatly appreciated so we don't have hours of downtime!
Related
Every time when open my file explorer and perform some operation it get stuck and starts buffering this problem has started to happen after when installed an solid state drive from a local store went to many stores but they were not able to fix it although tried many drivers but it's not helpful for me thanks in advance for helping me.
This just started happening for no good reason I can find.
If I launch the MSACCESS.EXE program, then open a database. The database opens within 1 second.
If I launch the same database by double-clicking on the .accdb file's icon. It takes about 40 seconds for the Access window to appear, and less than 1 second after that the database opens.
The database is local, and both Access and the DB are on an SSD. The system is an Asus Z97 motherboard, i7-4790K # 4MHz (not overclocked) with 32gb RAM and about 200gb of free hard disk space.
In both cases, performance after opening is excellent with no issues. It appears it's only the launching of MSACCESS.EXE by double-clicking a .accdb file that is affected. I double-checked the file association for .accdb and it points to the correct executable.
I captured some data with Performance Monitor during the 40-second pause. MSACCESS.EXE is using about 0.4% CPU, doing almost no disk I/O, and there's no network activity.
I've already tried "Compact and Repair" but that had no effect.
This just started happening, and now seems to be affecting Access on ALL .accdb files. They open instantly from within Access but take 40 seconds to open when double-clicked. I haven't installed any new software or Windows updates recently.
Curiously, if I change the .accdb extension to .accdr (runs the db in the client runtime instead of full Access) the database will launch instantly.
What could possibly be going on here? I've searched the web and found some posts having to do with databases on a network share, but that doesn't apply here.
For anyone else encountering this issue, it appears this bug has nothing to do with Access specifically.
I needed to shutdown the machine, and when I did so, Windows seemed to completely ignore multiple shutdown requests. As I was googling to troubleshoot, after about 10 minutes, the shutdown did finally start. It took another 10 minutes to shutdown.
After rebooting the slow launch problem no longer occurs, there's only about a 2 second delay, which I assume is just MSACCESS.EXE loading "cold".
So, the problem is most likely in Windows and not Access.
I spent ages looking for the answers to this on various sites but eventually cobbled together my own fix, so hopefully this saves others some time.
This worked for me and reduced the load time from circa 4 minutes - even just opening a blank accdb fle - to seconds... So 4 mins if double-clicking an accdb. Once MS Access open and using File | Open it was fast.
I had two instances of MS Access both on Windows Servers that can see the Internet but goes through a corporate proxy etc.
After getting some hints by Googling this issue I suspected that the 4 mins or so was some sort of timeout trying to access a site or sites (MS Office apps do this) and that eventually when the proxy returned a timeout then Access started responding again. It was quick on the 2nd open because it didn't redo this request.
Based on this, I tried to divert certain sites to 127.0.0.1 and turn off all the Internet options in Trust Centre | Privacy etc. Nothing worked.
Finally, I got the solution. In Windows Defender firewall I created a new Application rule for the MSACCESS.EXE. This was an outbound rule that blocked all Internet traffic. After this the first double-click was fast again. I assume with traffic totally blocked, whatever request is going out to sites, is immediately stopped and returns a "no internet" to Access, which then carries out executing, rather than waiting for the 3-4min timeout.
I have the following scenario:
WPF Application using SQLite-file per System.Data.SQLite on a windows-share as backend. Client is Windows 7 Home Edition
A user reported, that she was using the software, saving the new data she entered, but then after a while when she re-visited the software, some of her stuff was gone.
She said the session lasted until about 11:50am - the timestamp on the SQLite file in question was 10:55am. I have a logfile in the same network share, it is written to using a filewriter with autoflush.
The logfile looks normal until 10:55am, then there is one line with rubbish (looks like several lines written together in one), then goes on as normal.
Clearly the network (or maybe the drive) must have had a hiccup at that time. Miraculously my application just continued as normal. No exceptions were thrown, according to the logfile all transactions are "completed". No journal file remains to tell the tale. This behaviour - although wonderous in itself - is not appreciated by the user :)
My question: what happened here and how can I prevent it in the future? Did Windows 7 cache the file in the standby list and not care at all about comitting the changes to the actual disk? Why is my application or the SQLite provider unaware of this?
I will now build a confirmation mechanism that checks the timestamp on the backend file to see if it was actually changed at all after the last transaction, but that seems a bit silly. Just as silly as being very pedantic with catching exceptions when they are not being thrown :)
Thank you
TL;DR
SQlite file shows no changes after momentarily hardware (network or drive) failure, but the application seemingly continues to function and no exceptions are thrown by System.Data.SQLite.
See section 3 of How To Corrupt An SQLite Database File; it appears that Windows did not sync the network share when SQLite told it to.
My program creates a file, writes to it, closes it, renames it to something else. For one customer, the rename often fails with a sharing violation and I have been unable to recreate this issue.
The program is asynchronous and multithreaded, where the create and write are guaranteed to have been completed at the time of close and rename, but the close and rename may happen in any order due to being in different threads.
The customer ensures me that there are no av or backup programs installed and we have tried with Windows Search disabled.
When the close happens before or after the rename everything works (the file is opened with shared read+write+delete flags). However, when they are happening very close in time it sometimes fails. When running with ProcessMonitor, the error does not occur.
I know that the rename is made up out of several file operations (open, set information, close at least), so I assume that it is possible for the file close to be interleaved with the file rename, which seems be at the heart of the problem.
I am going to be able to work around the issue by ensuring that the file is closed after the rename. But I don't understand exactly what causes the sharing violation and I would like to know more why this is an issue. Can anyone give me more information on what happens?
I am trying to figure out when and how does Windows update File Access Times on files.
First of all, most Windows installs come with File Access Times disabled for performance reasons, so before wrapping your head around it here is what you need to do in order to activate last access times on NTFS file systems: modify the key [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem] value name NtfsDisableLastAccessUpdate to DWORD 0 value data(if it is set to 1 of course). If it doesn't exist just create it.
Upon reading File Times article on MSDN i am still in doubt as to how Windows updates access times.
My questions are as follow:
Do access times update upon issuing a WinApi CreateFile() with FILE_READ_ATTRIBUTES ? In my case, while doing it programmatically, it doesn't. Opening up the File Properties dialog of that file through the Explorer Shell does update the access time.
Do access times update upon issuing a WinApi ExtractIconEx() to read an icon from a file?
In my case doing so programatically, it doesn't. Opening up the File Properties dialog of that file through the Explorer Shell does update the access time.
If you ask me, both of those cases should update the file access times, but it seems to me that direct WinApi calls don't update them or Window/NTFS driver really lags behind, while operating on files from Windows Explorer do update pretty well. What do you think is or could be the issue here?
As a side note, i did do CloseHandle() as per:
The only guarantee about a file
timestamp is that the file time is
correctly reflected when the handle
that makes the change is closed.
My end conclusion is that, indeed the opinions lying around the web are true and Windows does update File Access Times in a random fashion and thus one really shouldn't in no way depend on Windows File Access Times.
Off-topic rant: Sorry forensics guys, you'll have to prove access times using another method or you can have your case invalided in seconds. :P
No, accessing the metadata of the file isn't going to change the last access time (name, attributes, timestamps). Wouldn't work well in practice, just looking at the directory with Explorer would change it. You have to actually open the file. ExtractIconEx() would normally be an excellent candidate, except that Windows can play tricks with it. A hidden desktop.ini file can redirect the icon to another file.
Using the last access time is pretty worthless for forensics. You'd need a file system filter driver. Similar to the one embedded in SysInternals' ProcMon utility. It might be using ETW btw, that got pretty powerful at Vista time. Nevertheless, your project just got 10 times more complicated.