Loosing data after entering it into access

[Cablek]

We have been using an Access database since 2000 we have upgraded it and it's currently being used on Office 365
As usual Access creates a unique number to identify the record
when reviewing the data I noticed a sequence of numbers missing from last Friday ( 3 numbers in a row) and this morning a few random numbers
There are 2 users using this same database and we have never encountered this issue before...

any thoughts?
Databade is 20,799,488 bytes in size
and holds 101703 records presently

 

[Cablek]

What was done to ensure that the record was actually saved? Did anyone close the form (you're not entering data into tables, right?) and re-open the form to see if it was still there? If yes, it disappeared after that? I'm not seeing anything in your info that confirms records are being deleted as opposed to not being saved. Is the number field an autonumber field or not? This may be practically impossible to troubleshoot from afar without looking at a db copy.

Well they aren't supposed to be entering data into the table directly but they are... instead of using the form they go directly into the table. once they move to the end of the table et saves the data....

I can supply a copy of the db if required

 

[Micron]

suggest you research 'secure access database' and/or review http://www.mendipdatasystems.co.uk/...7565/Improve Security in Access Databases.pdf in order to prevent access to tables. Still the questions remain:

What was done to ensure that the record was actually saved? and so on.

 

[Cablek]

suggest you research 'secure access database' and/or review http://www.mendipdatasystems.co.uk/download/i/mark_dl/u/4012650947/4635247565/Improve Security in Access Databases.pdf in order to prevent access to tables. Still the questions remain:

At this point we are just trying to make sure no NEW data is lost so they are being careful and making sure they do not start to entre then escape out (this causes an issue yesterday) The "switchboard that I originally created seems to be corrupted (empty slots) so I need to fix that before forcing them to use the form and not the table entre

Many years of updates I guess have taken it's toll... the info still seems tp be there it's just not displaying... this is what happens when someone who doesn't care os put in charge of a division

 

[Cablek]

So users have been inputing data from the form and not directly into the table but yet again yesterday 4 record went missing
I have copies of the w/o with the database number entry but recors is NO WHERE to be found.

This is a critical database used with ISO procedures

 

[Micron]

Normally I would suggest you post code that is behind the form, but if records went missing even after they were entered directly into the table then I don't see how code could be responsible. At this point, it seems that if you are certain that record entries were completed, they were visible in the table and now they're not, then I'd be creating a new db and importing everything into it. The Get External data has options to choose practically everything except (I think) relationships you created. If it's not db/table corruption then I don't know what it is, because you're certainly not near the db file size limit. If you do this and the problem persists, then I'd suggest recreating that table with a make table query then append the records from old to new. Copying the table over to a new db just might bring the problem with it. Having said that, a mt query to create the table might be the way to go right off the bat.

Perhaps start by copying the db, then rename the problem table in this copy (it's enough to add just one character in the name).
Create the new db and import everything into it except for the problem table. When done importing objects, link to the renamed table in the db copy.
Create a make table query in the new db, using the renamed linked table as the query source. Give the new table the old name.
After you run the mt query, check that the field types & sizes in the new table are the same as the original.
Delete the link to the old table (this does not delete the table, just the link).
Test and hope for the best!

 

[Cablek]

ok so I changed the "date()" to Now() and I got rid of the errors Access was giving me and was actually able to SPLIT the database ....but we are still experiencing intermittent DATA LOSS

They have been keeping copies of the w/o that are being entered with the record numbers that Access is giving and then POOF gone

any other idea's?

 

[jackd]

@Cablek,
A few questions:
-the database was written by you about 20 years ago (O365 did not exist then ), but it is now. Was there some testing/verification done during the conversion?

-when you split the database, you did give each user their own copy of the front end on their own PC, right?
That's how mutli-user Access databases are operated.

-Date seems to be in one of the Validation expressions or default value in Test Report Log.Entered. You could check that and correct as appropriate.

-This is a critical database used with ISO procedures

- do you have any sort of AuditLogging in place to identify who did what when?
- regular backup procedures?

I think micron has identified next steps.

If you are recording (separately) the W/O and you can identify which are missing, then
-is it 1 PC or many
-1 user or many
-anything specific in their procedure than what other users are doing
-any sort of pattern (time of day, sequence of ??, number of changes to record, ???)

You could take a copy of the current production front end and insert a routine to do some logging. But don't do multiple changes to