Ok this is a strange one

[BillCo]

I'm hoping I'll be proved dizzy and there's a rational explaination for
this.

User enters database - makes changes to a table. The changes are there
plain as day. User does other things in the database, comes back to the
data and it is as it should be with the new changes in place.

Then the user exits the database and goes back in. The edits in the
table are gone!

It's not a multi user conflict, it happens on a test setup stored on
the local drive with only one user. It is only happening on one table,
changes to other tables are sticking. It is not a linked table.

Here's the kicker: sometimes the changes do hold!

[Allen Browne]

Any chance the user has applied a Filter to the table, so that they are no
longer seeing all the records?

If not, I suspect the database is going corrupt. Try this sequence to stop
the problem recurring:

1. Uncheck the boxes under:
Tools | Options | General | Name AutoCorrect
Explanation of why:
http://allenbrowne.com/bug-03.html

2. Compact the database to get rid of this junk:
Tools | Database Utilities | Compact

3. Close Access. Make a backup copy of the file. Decompile the database by
entering something like this at the command prompt while Access is not
running. It is all one line, and include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

4. Open Access, and compact again.

5. Open a code window.
Choose References from the Tools menu.
Uncheck any references you do not need.
For a list of the ones you typically need in your version of Access, see:
http://allenbrowne.com/ser-38.html

6. Still in the code window, choose Compile from the Debug menu.
Fix any errors, and repeat until it compiles okay.

At this point, you should have a database where the name-autocorrect errors
are gone, the indexes are repaired, inconsistencies between the text- and
compiled-versions of the code are fixed, and reference ambiguities are
resolved.

If it is still a problem, the next step would be to get Access to rebuild
the database for you. Follow the steps for the first symptom in this
article:
Recovering from Corruption
at:
http://allenbrowne.com/ser-47.html
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"BillCo" <co**********@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

I'm hoping I'll be proved dizzy and there's a rational explaination for
this.

User enters database - makes changes to a table. The changes are there
plain as day. User does other things in the database, comes back to the
data and it is as it should be with the new changes in place.

Then the user exits the database and goes back in. The edits in the
table are gone!

It's not a multi user conflict, it happens on a test setup stored on
the local drive with only one user. It is only happening on one table,
changes to other tables are sticking. It is not a linked table.

Here's the kicker: sometimes the changes do hold!

[BillCo]

Thanks a million for your reply, very detailed.

I had the same instinct!
I ran a decompile - imported all objects into a new database, verified
referential integrity compiled and compacted... no corruptions, no
errors - and the problem didnt go away.

i was on the verge of looking for hidden replicas ...then i made a cup
of coffee and relaxed and came back to the problem and discovered that
my pre-decessor had put some very questionable code in the autoexec
macro that was buggering up the data on startup.

it's always something simple!!!! gurrrrr!!!

Keep up the posting - I've learned quite a bit from your archived posts
on google groups.