Access Database is getting corrupt again and again

Make sure the the 'reconnect' option box is unticked if you use the GPO drive map option. That will definitely fix it, did for me.

Our I.T department say we dont have this GPO drive map option, so unable to do this and access linked tables still getting corrupted daily

Regarding using the client side registry fix/hack...

has anyone noticed any general speed issues with the client PC

or any other unwelcome side effects in the general use of the PC for other apps etc?

I jave noticed one side effect of SMB registty fix to some other software created in Java and using the same access db as a backend with JDBC (similar to odbc). 

Java software was making rhe connection very slowly. This speed issue is appearing when we use the acces db together with the java program on the same pc (eg my frontend open and minimized and the java program trying to connect with serious speed issues). When tried to use the java program without my program open and connected to the same db, then java program performed quite well but not very fast again but faster than when my program was also open).

The wierd thing is that when my program is not connected to the mdb backend and I open the backend with double click like a single access file and minimize the ms access, then if after I open the java program, then this program runs very fast!!! 

All these are happening with SMB registry fix and server fix disabled on server.

With server fix no such speed problems.

Thanks for the reply. 

Regarding your comments:

1. Smb registry fix as you mentioned, works well and if someone uses it, then corruption dissappears. Same results we have with server fix, so smb is a solution when someone is not having access to the server
2. Smb registry fix is slower than server solution. Dlookup in complex queries is one reason of extreme slowing (as you mentiomed) for accrss applications in general. Bit It becomes terrible with smb registry fix while the same bad queries are performing faster with server fix. So I guess server solution is faster in everything since it handles very fastet these bad queries. 

But smb registry fix is also slower in other situations as well like:

1: complex dlookups (not inside queries) 

2: when viewing continous forms with many (thousands) records.. Form is opening very slowly

The make table query is a good and fast solution but if you perform it on eg on a big mde file locally, then size might increase and corruption issues of the mde might appear. So ot needs to be done perhaps to a seperated db dedicated for this

Regarding using the client side registry fix/hack...

has anyone noticed any general speed issues with the client PC

or any other unwelcome side effects in the general use of the PC for other apps etc?

Using dLookup inside a complex query is a disaster anyway as the function is called again and again for every row that is returned. Not sure why the server side solution would be much better. Using any of the  Access functions inside complex or even simple queries is not recommended - they are as slow as a wet week. They should never be used in such situations. Think about doing such queries in 2 steps - use a MAKETABLE to store intermediate results in a tmp table followed by an INNER JOIN on that table in a second query. It will speed up your application by a factor of many hundreds.

Anyway the upshot is that client side registry fix DOES WORK, preventing continuous corruptions,  and should be used in every case where you do not have direct access to the central server - due to IT not allowing registry changes to shared servers. The speed problem you are dealing with can easily be overcome.