Best practice for edit modes to prevent accidental edits?

[NoellaG]

Something that might work in my experience: take the user out for lunch or go and have a beer/glass of wine together. DO NOT talk about business, application, IT on this occasion. Just try to get to know each other. More fun than talking to the boss

[CJ_London]

You could modify the routine to do that - have the app ask for the number of records required then generate them already populated with the defaults so the user just has to enter the manual records

however it does sound like your schema/form design is not normalised as it unusual to have repeating data

[rdougherty]

If you can't negotiate cooperation, you're going to have to find a balance between unlocking a record so it can be edited, then locking it again. As I've already mentioned, you can avoid this with a form that opens to only one record. Or you can make the form show a single record and use navigation controls (I'm assuming you're using a continuous or datasheet form and making it too easy to load many records in one view, which might be incorrect). Or some other design idea. Or the boss of both of you needs to hear why you're getting so much push back.

The form is a split form, loading the whole recordset of the table, with a locked datasheet view above the form view. She is doing this behavior because the datasheet view is not editable, so it is sort of an act of defying the forms design out of a sense of entitlement to do data entry in the manner she personally likes rather than in the way that ensures the best integrity. She is very uppity and is resentful of the fact that I, a trainee of hers from a 3 years ago, is being given more advanced assignments than she is, in some areas

Edit to add that she is younger and has never worked in a professional setting or really know how to type... so, just by default she is not going to listen no matter how I present it or tailor the Db to match her preferences while trying to balance that with data integrity.

We were very good coworkers and pseudo-friends most of this 3 years. We know each other very well. This changed when our old boss was fired, and we started to fear our jobs would get cut. This probably stems from a need to prove herself as more valuable and cast me as the guy who is a problem.

The form does a copy of some defaults because each record needs to have some of its own details which differentiate it from other records (parts in a batch of 10-30), but will have common job#, Inspector, tag#, and accepted dates. It would do nothing useful to split that stuff into a separate table and relate it. The data entry steps would be no quicker, and dev would take longer. (Note, not all of our parts even come in batches, so the main table would need these fields anyway.

[NoellaG]

It would do nothing useful to split that stuff into a separate table and relate it. The data entry steps would be no quicker, and dev would take longer. (Note, not all of our parts even come in batches, so the main table would need these fields anyway.

useful when using the correct data structure:
- data integrity: no double/repeating data
- easier maintenance
- less development: no need for automatic copying
- every extra action (like copying) is a possible cause of extra errors
- smaller databases
- faster queries

[rdougherty]

Without showing you the data itself, and a copy of the database, it's hard to explain... but if you saw how varied our physical processes and data collection are, you'd see that the current design is the most flexible for how we do business, and how dissimilar our wide range of parts can be, and vary based on the day or situation.

Basically, having a form to sets some defaults for a set if similar records is preferable to a related table for a "batch" because, depending on the situation all records in a set could have all but one value in common, or as few as only one value in common. Most of our parts do not have anything in common. Moreover, setting some batch defaults allows the user to set a value for all records, and then change the few values that are not identical. For instance, if "Inspector initials" is identical for all but one record in a batch, so that the value can be defaulted for all of them, and set manually for the one.

[NoellaG]

You might consider an approach like we do in the lab database. We can perform different analysis on one sample, some are fairly common others can be very different, a bit like your batch and different values. So we have a table with common sample fields like the sample nr and sample date. We have a table with a list of all possible analysis and a separate table with which analysis are performed for the sample and the result values. See the simplified schema in attachment

[Welshgasman]

I entered over 20k records, where two of the four fields were the same for about 13 records at a time.
I just had a flag as whether to set the defaults for those duplicated fields to the previous record.

[HiTechCoach]

For me best practice is to do what is best for the user's productivity and reducing errors.

Unfortunately, most developers have rarely used applications like they create. Using the application for 8 hours a day for several months. Because of this, there is often a negative impact on productivity.

When I start 40+ year ago as a developer, I first spent months doing high volume data entry for 8 hours a day. I did the work of the users first to understand their needs. I understand first-hand what it does to a data entry person's productivity by just making one small change to a form. It cost the business money by slowing down data entry and time spent fixing errors. Because of this experience doing data entry, I have been able to actually increase productivity.

User's generally resist change when it does not dramatically improve their productivity.

Making a fast and simple data entry form requires a lot more developer skills and understanding what makes for faster data entry.

Using Access's form event can eliminate the need for an edit button to avoid accidentally editing the incorrect record.

I have created forms that look like entering in Excel or directly into a table.

If this were my project, I would run through testing comparing original method with any new method to see the impact on speed. The original method's productivity level will be the benchmark. Any new method should be more productive.

I have not had users resist changes when they can see the improvement in productivity using their own benchmark.