Access Data Loss Problem

[jsteel]

Hi,

I'm a network manager at a school running 5 windows server 2003 servers (3 of which are DCs) and 350 windows XP clients. Network speed and traffic is excellent and most of the time the only software used is microsoft office. Most computers run office 2003 but some have office xp.

Here are a few scenarios of the problems:

Scenario 1
A teacher looks back at some work of a student who left a year or so ago to find all work as expected however all access databases are empty (no tables, forms etc. Just blank database files)

Scenario 2
A student says they were working on an access file only moments ago and everything vanished (resulting in a blank database file). They claim the file has been there for weeks, and has had data in it for weeks. They have been working on it a number of times a week. When I look through the backups, the database file exists but is empty on every occasion.

This problem occurs over 4 ICT suites (120 computers) at random and is always a different user. There seem to be no patterns. We get the Scenario 2 problem about once or twice a month, although sometimes a lot more and sometimes a lot less.

Any ideas or comments?! (I need some response even if it's not very helpful!)

Thanks,

Jonathan

 

[MStef]

Hello Jonathan!
Use SCROLL BAR, there must be somewhere.

 

[jsteel]

Hi,

Do you mean 'scroll down'? I'm afraid that isn't the solution to my problem.

Jonathan

 

[neileg]

Not a solution, but some thoughts.

It's not easy to completely empty a .mdb file. Sure you can delete objects but you can't even select multiple objects from the db window and delete them. The quickest way to mimic this wholesale deletion is to create a new .mdb file with the same name and overwrite the original. Are you sure that there's not a rogue program (virus, etc) doing just that?

Scenario 2 is implausible. If the .mdb was working today, then yesterday's backup must also work. Unless, of course, there's this rogue that is switching file names.

 

[MStef]

As I have said, try with SCROLL BAR (on empty access window).

 

[jsteel]

We run sophos anti-virus which is kept up-to-date.

I understand that this seems very strange but it's becoming a regular problem.

Regarding 'scroll bar', can you explain further please?

Thanks,

Jonathan

 

[MStef]

When you try to open mdb and the ACCESS window is empty,
do you see a SCROLL BARS ???. Move them (vertical or horizontal),
your mdb window must be here somewhere.

 

[jsteel]

As I said before, scrolling is not the problem. There are no scroll bars, it is as though the files are "new" - completely empty.

Jonathan

 

[neileg]

Anti virus software won't pick up something that has been written in house! In my experience, the biggest threat to any school computer resource is the students...

 

[RuralGuy]

Can you still see the Database window? Does anything change when you go to Tools>Options...>View tab and check Show Hidden objects? How about Tools>Analyze>Documenter? Does the Documenter see any objects?

 

[Pauldohert]

Tyr creating a new record - just to see where the primary key is up to - will tell you if data is really misiing or somehow the database is clean/new - ie the PK has gone back to the seed value.

 

[The_Doc_Man]

This is going to be a "stream of unconsciousness" response. It is the things I would check reflexively whenever someone says "data loss" in ANY program, ANY application, ANY file - where the file is still there but the data isn't.

1. Check Windows file permissions and ownership to verify that BACKUP is ALLOWED to read the file. Be ABSOLUTELY SURE that nobody has put a "DENY" permission in the file that could apply to the account that does your backups. I've seen cases where the folder allows READ access - so you can see the file header and directory markers - but the content is not allowed to be backed up. You get empty files on restoration.

2. Windows file systems (NT and later) maintain a series of dates on files. You should be able to check "last modified" date and compare to student claims of it being usable yesterday, gone today.

3. Taking the "last modified" date, look at the server's logs (Event Viewer function) for all "session created" and "session ended" events that cover the indicated date. See who had started but not ended a session.

4. Get your security manager to do this. For a short period, add an AUDIT ACE on the file such that any student user successfully opening the file will be logged to your AUDIT event log. You probably don't want this to stay in force too long - the audit logs get cluttered all too easily as it is.

5. Go into one of the affected MDB files. From the Options, get it to show you all SYSTEM and all HIDDEN tables. If mSysObjects is still there, you can use the Tools >> Security options to see who OWNS the tables and any other objects.

6. Look for hidden modules to see if you have a hacker who is too damned cute for his own good. If there is a switchboard form, check the class modules for unexplainable code that might gut the MDB files.

7. Office lets you do a re-install to REFRESH your installed options without changing any settings. XP allows you to do this and it will still track the updates for you so that you don't endanger your computers. REFRESH the copies of Office to see if something is corrupted.

8. Open a module page. If necessary, create a blank module. Let it live only long enough to check your references. Use the Object Browser on those modules that allow it so that you can see what is in the objects associated with some of those references. You can usually see things like .DLL and .OCX references via the browser.

9. For your critical databases, implement workgroup security. Search this forum for articles on how to do this in a way that prevents users from logging in via a default workgroup file.

10. For your backup software, see if it keeps log files. If so, look at the logs to see if it noted an action for your missing MDB contents. If it CAN - but DOES NOT - keep log files, ask your Operations crew to enable BACKUP logging. Also look for backup program settings like "silently skip backup of open files" and any other settings that can affect file contents.

11. TEST YOUR BACKUPS on a regular basis. Manually make a backup and then verify that the file is, in fact, recoverable using that backup program.

12. If you find that this was an act of outright computer vandalism, I can tell you that the Admiral for the Navy group where I work has been quoted as saying, "Execute one, educate many." Sometimes it is hard to know when he is kidding. So get to a hardware store and buy a new rope. Tie yourself a good noose. Hang it in the window of your machine room. Put a sign on it that says "Reserved for hackers only."

 

[MStef]

Hello Jonathan!

If you see the DATABASE WINDOW, stretch them with a mouse.