corrupted database

[helena]

Hi!

I have a VB application that uses an MSAccess 97 database. There are many
users accessing that database throught Terminal Server. After a few
connections the problems appear. The database stays corrupted and the users
are not allowed to connect to the database without first repairing it.
I used LDB Viewer and there values indicating that users accessed corrupted
pages.
Someone as ideias about what's going on?

Thanks

Lena

 

[petermeachem]

How many is many users. Phrases like 'Access' and 'many users' only usually appear in the same sentence if there is a 'not' as well.

 

[Terpsfan]

The LDB file merely shows which users were accessing the database at the point of corruption. The LDB file keeps tabs on record locking. Access was never meant for many simultaneous users, but anything less than 10 should be fine. If you are continuing to have problem I'd look into upgrading to SQL Server.

 

[helena]

well, I don't know much about the problem, but the person who was trying to find an answer to the problem says that

"I have an application that uses DAO and Jet3.51 to create a multiuser environment.
Some months ago I began receiving some "3343 - Unrecognized Database Format"
messages. The network was checked and everything was OK.

I found out that if I open several times my application, the LDB file appears
with several repeated entries. Is this OK? (I don't think so)

Another problem is: if I have a Terminal Server accessing an Access database in a
remote server, all the computers connected to the terminal server will appear in
the .ldb file as the terminal server himself. This will cause more repeated
entries (in the .ldb) and conflicting access to the database (I think)."

and

"I think the locking on the database is done using the "computer name" as
identifier. When you use the terminal server to access de database, all the
computers will have the same name (the name of the server). This will cause,
in
my opinion, confusion in the locking system."

Does anyone know tools like LDB Viewer to diagnose the database?

If anyone could give as some help we appreciate a lot.
Thanks

Lena

 

[Blondie1572]

Lena

I operate in a similar environment and also intermittently have this problem. Microsoft explain this error with "This is typically caused when the Jet database engine was improperly shut down during the process of writing to disk". Very helpful.

Unfortunately I'm still looking for a solution, however I would warn you that I am also experiencing unexplained data loss so keep a close eye on the number of records in your tables and operate a 5 day minimum rotational backup.

 

[MatsHulten]

I know this subject has been up before in this or VB General forum, and a possible soulution (and explanation) was offered.

Unfortunately I can't remember the name of the thread, and when I tried a search I got about 2000 results...

If you got the time and patience the answer is out there...

If you havent already, I also suggest that you try the question in the Access forum.

Good Luck
-Mats Hulten

 

[helena]

Mats

What keywords did you used to search?

 

[MatsHulten]

ldb corrupt access users

Remember no commas (',')

Any luck?
-M

 

[BBaggins]

Check for RealTek NICs - replace them if practical, update their drivers if not.

If any of the workstations are running the Novell client, make sure it's version 2.2 or higher, and that file caching is turned off (set the following key to 0: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetWare\Workstation\Parameters\File Caching)

If client is Win95, make sure VREDIR.VXD is version 4.00.1112 or higher. Also make sure that HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VREDIR\DiscardCacheOnOpen is set to 1.

Make sure you delete the .ldb file after you resolve a corrupt database.

Try to compact the database before repairing - the Access repair feature often causes more problems than it fixes.

If you can't open the database in Access, manually reset the dirty flags (offsets 0x600 through 0x6EF) using a hex editor. Take a look at the file header of a non-corrupt mdb to see what the flags should look like.

 

[StewC]

We operate a similar environment and have the same problems. Have gone through the usual channels and it seems that no one on the planet knows why a jet database corrupts. Take a look at microsoft article below -

http://support.microsoft.com/support/kb/articles/q294/8/16.ASP

If this is the case, we all have a major problem!
Anyone know anything else on this one

 

[Guest_imported]

We have just tested this. It is definitely a problem in Terminal Server. The solution is to establish a session and in that session open the database file which resides over the network. Then make sure that that session remains connected at all times and before any other sessions. This should ensure that the NBT connection to that file is not lost.
It is not a good solution but the only practical one that we could think of.

Hope this helps.

 

[StewC]

We have moved on since the last post quite a bit. There are numerous issues with jet databases and windows 2000.

Microsoft have now released some patches for the problem and we have applied their suggestions in the relevent articles.

Up to now we have had no corruptions in over three weeks (hope I'm not tempting fate here)

Relevant articles to work off are Q303519 (particular attention to oplocking) and Q272582 (hotfix available if you badger them)