disappearing records

[aquitaine]

Hello,

I have read a few other queries about this problem, but none seem to help me.
I have a database, not too large (c.2000 records), not too complicated (very few macros, no referential integrity, no reports, mainly simple queries).
Over the past few weeks records have started disappearing. Vanishing, no trace. No pattern to the record numbers. About 220 in all have disappeared so far. There is a main table (manuscripts), with links to other tables (manuscript notes, manuscript decisions). The records disappear from the manuscripts table, but the related records are left in the other tables.
Only five people use the database, no one has deliberately deleted anything in fact as we keep all information.

I have read other posts about how only a user or a query deletes records, but there are no delete queries in the database. Users do not access the tables, only forms, and do not delete anything. Many records that have disappeared were ones that were no longer consulted for any reason, so no one would have even opened the form.

Could this be a virus? I cannot believe that the database is too large.

any help really appreciated.

Thanks

Eleanor

 

[jsteph]

Eleanor,
It's definitely not a virus.

no one has deliberately deleted anything

It's probably someone accidentally deleting a record. Just hitting the Del key while on a record can delete it.
--Jim

 

[Trevil]

In MS-Access, I have only seen records 'disappear' for two reasons:
1. A user took some action (query, form, table, code) and deleted the record -- either by accident or intentional.
2. Database table became corrupted - BUT records still appeared in table view as all "####' -- you just couldn't access them.

Do your users only access the data via forms? If so, set the Form property "Allow Deletions" to "NO"

When you store a Manuscript record do you ALWAYS store a related record in some other table? If so, create a relationship, but make SURE 'Cascade Deletes' is not checked. This way if someone tries a delete by accident, it would prevent it.

Other options would require a lot more effort:
1. set object security to prevent deletes. Would require a different Workgroup file.
2. Have some process that forces users to log into application. Capture record counts when they come in. Later, check the table and see if counts decrease.
3. Prevent users from seeing the database window (in case someone is going into table view).
etc.


"Have a great day today and a better day tomorrow!

 

[aquitaine]

Thanks Jim, but I just don't see how this can have happened 220 times! Many of the disappeared records are 'rejected' manuscripts, from 1-2 years ago, meaning that no one would even have looked at them. It has not happened in the 18 months I have been running this database.

Any other advice on replacing the records would help - I have a backup copy from the end of June, before this started happening, but cannot copy & paste the records (autonumber problems, error messages about text being too large for field etc) I have not changed any field sizes so this doe snot make sense either!

Eleanor

 

[jsteph]

Eleanor,
Maybe not 220 single times, but it's possible someone was trying to 'help' and knew enough about Access to be dangerous, and deleted those records.

Trevil's point #2 is the next most likely scenario. However, to me, it's too coincidental that it's only records that are rejected--corruption usually will have a more random swath of damage, and even if it's all older records (that might be all part of contiguous pages that got corrupted) it sounds like a line was drawn and no newer records were deleted? This tells me that someone filtered a set via a datasheet or query and hit the delete button.

But definitely not a virus.

To replace, import the backup table into the database, then create an Append query that maps the fields to the destination current table (just dragging all fields should automatically map them), but don't use the autonumber field in the query--it'll generate itself.

The 'too long for field' error probably just means that some fields are mis-aligned, this is why I suggest the Append query.
--Jim

 

[reb5555]

To stop something similar on my databases, I created record in a history file for every changed record. This way I know what & how it was changed. I use a form & have changes cause a value of one in a cell. Then before the form closes or as it opens it runs an append query to another table.

 

[TheAceMan1]

How are ya aquitaine . . . . .

In any case, you should [blue]only allow deletions by specific users.[/blue] In all my DB's unless specified by the owner, I have a popup that notifies the user to contact administration for this. [purple]This would at least stop any future loss of data![/purple]

From day dreaming to intent to clickitis, you'd be suprised what people can do. Have you ever stood behind a user and just watched?

BTW:

[blue][purple]Clickitis:[/purple] That condition which occurs when the finger keeps going, although brain to hand is disconnected.[/blue]

See Ya! . . . . . .

 

[aquitaine]

Thank you. Actually I solved the "mystery", which was that of course you are all right and someone ran a query and deleted all the records - I think probably did 'cut' instead of 'copy'. It was on the only one query that is not protected as I cannot work out how to run it from a form. I have now deleted this query and prevented deletions on all other forms which is irritating for everyone but serves them right for wiping over the weekly backup even after noticing missing records (I was on holiday).

Thank you for the hint of specific user deletions and pop up messages - I will try that.

So, sorry to Jim if he is still reading this that I doubted his advice!

Eleanor

 

[assets]

As other have states.

1: there is a FAQ on making records read only and you will need to have a edit button to change the record.

2: there is a FAQ on Audit Trail that shows changed made to a record ( name using the login name). If the record is deleted then this field is also deleted.

Look at security options als some usefull info in FAQ and posts.




Never give up never give in.

There are no short cuts to anything worth doing