Access Database is getting corrupt again and again

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]

"FileInfoCacheLifetime"=dword:00000000

"DirectoryCacheLifetime"=dword:00000000

"FileNotFoundCacheLifetime"=dword:00000000

He says: This approach is more easily implemented in my setup program

Can I ask how Mark did this?

I think I will go down this route

I use Inno setup as the installation program

Can someone advise the best way to do this?

I was thinking...

Do I create a .bat  'regfix.bat' with these exact 5 lines above, include them in the install program and then run the bat file at the end of the install program?

[Run]
Filename: "{app}regfix.bat"; Parameters: "install"; Flags: runhidden

I posted this thread earlier about coping files. I do not know why it worked but it did.

Has anyone read through that thread it might provide some additional incites to what the issue is here (it is only 2 pages as opposed to the 33 here).

It is curious why it showed up in Access a year or so before it showed up when coping files???

https://answers.microsoft.com/en-us/windows/forum/all/drag-and-drop-to-network-folder-icon-not-working/d6db3ede-1cea-490d-bf49-339d178174b0?auth=1&page=1

Mark - I was skeptical too but tried it & it worked. As I mentioned, I did three things (ie. Move the BE database to a different folder, relink the BE tables to the front end & switch on the "Compact and Repair on Close" option). I am not sure which action(s) fixed my daily database corruption issue, but it did.

It is a relatively simple fix vs trying to convince your IT Support to implement registry fixes on your host server or on all your client workstations. I would just try it, and if it doesn't work, go for the other server or client workstation registry fixes. Unfortunately, many developers gravitate to the more complex solutions rather than just testing a simple fix. I'd rather implement the simple fix and go on with my life. Just saying...

It does seem extremely unlikely that this will prove a permanent solution, but I guess moving the back end periodically could be viable for some sites where the Registry changes are not allowed. I wonder if simply changing the back end file name has the same effect (i.e. any change to the full (back end) database path).

This might partly explain the difficulty MS have in reproducing the issue; perhaps the (back end) database path needs to be in use for an extended period before the bug arises. (Also bearing in mind that various Windows Updates seem to have triggered it in many cases, and caching seems to be involved.)

Hopefully this will provide MS engineers with much needed clues. What do you think Shane?

George,

I guess I am amazed and a bit skeptical that just moving the back end database to a different folder on the server and relinking the tables on the front end would resolve anything. I am glad it is working for you and I hope it is not temporary. I am sure there are varying levels of how deep the path goes to the back end database as far as folders and sub-folders if we would survey the people here who are experiencing this problem. So I am wondering what the trick was in your case if this does indeed permanently resolve your problem. Or was there some other change that occurred at the same time such as the frequent compact and repair? I am just a bit puzzled by your results, while at the same time happy it helped you.