MSAccess MDB corruption

[qusayamari]

Migrated VB6 (MS Access 2003) based application from Windows Server 2008 Enterprise to Windows Server 2008 R2. The application is accessed via network share from Citrix XenApp.
Since the move, we have had an almost daily corruption issue in one of the mdb files. Does WIN2K8 R2 behave differently than WIN2K8 Enterprise in terms of handling open sessions? The Citrix servers reboot nightly – some end-users are bad about logging out correctly and leaving sessions idle.
Is there a file monitoring tool, script or some other method to monitor the file for corruption and send an e-mail notification?

[zmbd]

I'll have to look into this a tad deeper; however, we used to have this issue with older access database backends accessed over the networks when the network server would reboot because it would simply force the file to close irregardless of the write-state or record locks resulting in corruptions.

There are some threads here about using the timer event in forms to close idle sessions. You can use the search bar at the top of this page to find them :)

[jforbes]

Using a timer to close the database connection may work, but in my experience with Terminal Server, when the Session isn't actively being used by the user, the applications that are opened on the users desktop effectively pause their execution. So in the case of a user disconnecting their session, the application will stop and wait indefinitely, without exiting, and a timer will never be fired.

I think there is an option to force a Logoff after a certain amount of idle time. Forcing a Logoff may allow the application to Exit gracefully and close the database connections. Or alternatively, force a Logoff before rebooting the Server.

Or to switch gears completely... This is not necessarily a recommendation and it may be way off target with what you are doing or with your company's capabilities but your backend database could be converted to SQL Server or SQL Server Express. It should take care of your file locking/writing issues and then you can just let your users be as careless as they like.

[zmbd]

I think your problem lies with the Citrix XenApp.

Citrix XenApp is an on-demand virtual application delivery solution ...

Understanding application virtualization

Citrix application virtualization technology isolates applications from the underlying operating system and from other applications to increase compatibility and manageability. As a modern application delivery solution, XenApp virtualizes applications via integrated application streaming and isolation technology. This application virtualization technology enables applications to be streamed from a centralized location into an isolation environment on the target device where they will execute. With XenApp, applications are not installed in the traditional sense. The application files, configuration, and settings are copied to the target device and the application execution at run time is controlled by the application virtualization layer. When executed, the application run time believes that it is interfacing directly with the operating system when, in fact, it is interfacing with a virtualization environment that proxies all requests to the operating system.
(...)

Your program is in an active state within the XenApp and when the server reboots it wipes out your connections and anything else that is pending.

I would attempt the Form Timer first.

I my experience, forced logoffs from the server are never a good thing and have found that there is 50/50 chance of breaking something at the client's end.

The Terminal Server issue that J talks about can also happen; however, there are workarounds for that... the easiest, as J suggests, may be going to the MySQL, MariaDB, SQL-Server, SQL Server Express, etc... however, that may not be for the faint of heart.

[jeroennetters]

The repair method attempts to recover only the tables, indexes and queries in the database. Do not attempt to repair damaged forms, reports, macros and modules. Before executing the Compact and Repair tool, please ensure the following condition:

1. Do not open Access database must closed
2. Sufficient storage space available - minimum double in size of your Access database on that Disk.
3. Close the .mdb file related to .ldb file before you delete the .ldb file.
4. Then Run the Compact and Repair tool

In case this methods appeared ineffective look at professional software for corrupted .mdb and .ldb files in MS Access.

[efrainday]

First of all make a copy of your database file when Access is not running.

When an Access database file (mdb or accdb) is corrupt or damaged, then you can try several methods to repair and recover data from it:

1. First of all, try compact & repair. Follow below steps:

For Access 2010, click Compact and Repair Database on the Database Tools ribbon.

For Access 2007, click the Office button (top left), then Manage.

For Access 95 - 2003, choose Database Utilities from the Tools menu.

2. Second, if method 1 does not work then try to create a new Database and import all the objects from old database into new blank database.