Question Adding New Record Periodically Not Allowed

[DC1]

I have a VERY simple completely self-contained database with a single user. It is for a dental school at which students are required to go on service trips with their newly developed skills. The database's core is 3 tables: a table for service trips that students can go on, students who may go on those trips, and a junction table linking the two in a many-to-many relationship. Data entry is done literally from the trip table with a +/- node allowing addition of students to the trip detail table.

About 6 months ago, the user's computer was replaced and their office suite was upgraded from 2003 to 2010. Since then, periodically they have called me to say that they are not being allowed to add students to trips.

Here are the paths I have taken:

1. Checking and discovering that I, accessing the same database from another machine, am able to add students to trips;
2. Compacting and Repairing the databse, which did NOT resolve the issue;
3. Opening a brand new database and importing all the objects into it, which DID resolve the issue, temporarily.

I just received an email today stating that it has just happened for the 4th time. I can repeat my above-mentioned fix which will probably resolve the issue - again - temporarily.

Are there any thoughts on why this might be doing this, and if there are any insights which might lead to a permanent solution?

Any thoughts would be appreciated!

 

[jdraw]

Are you saying you do data entry directly to the table -- NOT through a Form which does some validation?
Do you have any error handling routine(s)?
Did you test the new 2010 version with real data?

 

[DC1]

Yes, entry is directly into the tables. Consequently there is no error checking. And, there was no testing done for 2010. Just to clarify my role: this was a database already extant when I became involved and I serve as a consultant who services it when issues arise. Thus, the design had nothing to do with me and the upgrade to 2010 was done without my knowledge, let alone forewarning.

Having said that, the database is so extraordinarily simple that error handling routines seem extraneous. Plus, I can add records when the single user is prevented from doing so, and the above procedure restores their ability. There is nothing wrong with the data.

 

[JHB]

..Plus, I can add records when the single user is prevented from doing so ...

In the same database?
Are they sending it to you by E-mail or how?
I would have a look at how they close the database after they have done some change(s) in the table(s), (if they step out of the field in which they made changes before the database is closed.).
Working directly in the tables isn't a method I would recommend.

 

[DC1]

I appreciate your response to the question and the effort to offer some suggestions. Below are my responses to the questions and observations.

----------------
In the same database?

Yes. Exactly the same database.
----------------
Are they sending it to you by E-mail or how?

I'm not sure what you mean by sending it to me. The database is on a server to which I have access and I open the exact same mdb file.
----------------
I would have a look at how they close the database after they have done some change(s) in the table(s), (if they step out of the field in which they made changes before the database is closed.).

This might be a question worth asking. The only observations I would have are that: 1) this is a pretty fundamental function of Access, and leaving a record by any means will commit that record, and; 2) the same user has been using the same database for at least three years without incident, until the upgrade to a new computer and Office 2010 from 2003. And, the database itself, with predecessors included, has been used by at least 3 different users for 10 years without ever exhibiting this behavior.
----------------
Working directly in the tables isn't a method I would recommend.

I understand that working directly in the tables is not a best practice. But, given the utter simplicity of the structure and the existence of only one user at a time whose intentions I have absolutely no misgivings about, and the history of using the database exactly as it was initially used, the development time to create a user interface seems uncalled for (though unquestionably better practice).
----------------
Somehow, comments about working directly with the tables seem a bit misdirected. Unless somehow working directly in the tables could, in itself, cause this behavior, it seems to miss the point of the original question. It seems extraordinarily unlikely to me that that could be the problem, given the fundamental nature of the record-commit process, the decade-long usage of the database with exactly the same entry method, and the conspicuous coincidence of the emergence of the problem with upgrading of the machine and of the Office Suite. Maybe I'm missing something, but it just doesn't seem to add up.

Again, thank you for your involvement and suggestions. I hope my responses are helpful to the discussion.