Access database on the network is getting corrupted

[chromarog]

I posted this in the Office forum and have been keeping an eye on the thread but I would like to ask the Novell guru's this as well.
thread68-432977 is a snip from the descrition from the above post:
When a user opens up an Access database, the LDB file is created with info of who is opening the file, among other things, right in the directory the database resides in. When the database is closed the file deletes itself. For some reason the files are not deleting and this ultimately leads to an "unrecognized file format" error message. The database is then corrupted and needs to be restored. The details are a bit sketchy on the events the lead right up to the crash and MS and Novell are not really revealing much about or not much is know at this problem. Now no-one can confirm that the LDB file is causing the unrecognized file format error, AND no-one can confirm that the file is even there 100% of the time when it happens, but it has been noted in most of the cases that they have looked.

Any related experience with such an issue would be hot. Patches:
Novell 3.31 on 95/98 machines
Novell 4.81 on 2k machines
Office 2k SP1
Novell Servers are 5.1 with SP3 and SP5. There have been problems with this on both servers.

The client has file caching turned on in netware properties due to the network admins don't want the users to have a performance hit. The databases are multiuser databases.
</snip>

The LDB file not deleting itself is NOT the cause of the problem but can be a contributor as posted by Dreamboat and JimInKS. One user was performing duties in 2 different physical locations but the context remained the same. That problem has been caused due to user closing the database and shutting the machine down in a matter of seconds. Due to the trip from servers and locations that was the cause of the one problem. But any other information or experience with this is greatly appreaciated.

Thanks,
Rog

 

[TheLad]

People who read my posts won't be surprised to read what I type next as my first suggestion in cases like this is always the same: Turn off file caching on your servers. This does not have a performance hit, infact I can provide several Novell TIDs that mention high utilization on the server with File Caching turned on. Anybody says different, they have been caught in the File Caching myth and they can put their argument to me and I will correct them if they like. I will even show them TIDs where Novell recommend switching file caching off.

To do this, type SET CLIENT FILE CACHING ENABLED = OFF at your server consoles. This also needs to be set in STARTUP.NCF.

Also, try updating your versions of the NetWare Client. Latest for 95/98 is v3.31 SP1, latest for NT/2K/XP is v4.83 SP1. -----------------------------------------------------
&quot;It's true, its damn true!&quot;
-----------------------------------------------------

 

[chromarog]

Thanks again, I'm not sure if that will help. But low and behold file caching was ON on the server side. It got defaulted to ON at SP5 implementation. We'll see if that corrects the problem. Thanks again TheLad I really appreciate it. Now I'm sure they'll make me do more work.

Rog

 

[FRUX]

Try to set this properties at the Windows Netware Client &quot;Advanced Properties&quot; tab:

- Delayed Writes OFF
- Cached Writes OFF
- Opportunistic Locking OFF
- Packet Burst OFF
- True Commits ON

 

[creslan]

I had an ldb problem with a shared access mdb file too. It turned out to be related to the users' rights to the folder that the database was in. I had removed some rights to keep people from deleting my database files or putting other junk in the folder, leaving browse, read, modify. This turned out to be a bad idea because the ldb file could not be created. So I allowed Create. Then, when the last user exited the database, I found out the hard way that I had to allow Delete also, so the ldb file could go away. So I ended up having to allow full rights to the folder, and I protected the database file only. I had a pretty simple directory structure, but you may have a problem with access restrictions being carried down through your directory tree. Verify that your users can create and delete files in the folder. After some unrelated database corruption problems, I gave the mdb file the Transactional tag. I don't know if I should have done that, but no problems since. The only problem now is that I have to uncheck the Transactional item before I can compact the database. Also, make sure your User Record Locks is set high enough - I've had problems with this being exceeded when making bulk changes to large access tables. If you exceed the limit, it will be reported at the server console along with a lot of beeps.

 

[TheLad]

If you are worried about people deleting the database, you can always flag it Delete Inhibit? -----------------------------------------------------
&quot;It's true, its damn true!&quot;
-----------------------------------------------------

 

[creslan]

I think the Transactional covers deletion and protects it in a variety of ways. That's why I have to uncheck it to compact the mdb file.

 

[nikky]

I had a similar problem, it turned out to be related to the network connection ( wiring / hub port). Fixing the network connection resolved the problem.