Locked field preventing update.

[stevekos07]

Hi. This is an annoying "thing" that happens from time to time and I need an answer. I have a multi-user database that is updated frequently in real time. From time to time we find that a user fails to save or exit a form and leaves their cursor "active" in a field. This prevents that form from saving because the user has the field in "edit" mode.

Is there a way that this can be overridden so that all fields are cleared to allow the form to save and update the table?

I hope I am making sense.

 

[Galaxiom]

Dirty records on a bound form are saved automatically when moving to another record, closing the form or exiting the database. Having the cursor in a control on the form makes no difference. There is no "saving" for a user to do.

Either you have an unusual form construct or you are mistaken about the cause.

 

[The_Doc_Man]

Multi-user database? I have two questions, to be considered in either order.

Is this a split front-end/back-end database or a shared single-file database?

If this IS a split FE/BE database, is the BE Access or something SQL-based?

 

[stevekos07]

Multi-user database? I have two questions, to be considered in either order.

Is this a split front-end/back-end database or a shared single-file database?

If this IS a split FE/BE database, is the BE Access or something SQL-based?

It is a split FE/BE with Access BE.

 

[stevekos07]

Dirty records on a bound form are saved automatically when moving to another record, closing the form or exiting the database. Having the cursor in a control on the form makes no difference. There is no "saving" for a user to do.

Either you have an unusual form construct or you are mistaken about the cause.

In the situation I am referring to, the user is not completing the entry into the field, but leaving the cursor in the field in "mid-edit". This is unusual in most situations, but in the environment we work in, an operator may be interrupted in the middle of writing to a record and attend to other developments. If it happens that the operator forgets that they have done this it means that the backup will be affected. It is worse when the operator is no longer present at their work station for an extended period. I didn't think that a half-edited field would register anywhere other than on the operator's copy of the form, so this is a bit baffling.

The form construction is normal as far as I can see.

 

[The_Doc_Man]

You are correct that this seems to be unusual behavior. Access does this when you tell it to do something unusual. By any chance is the form set up for pessimistic locking? Or if this form is driven by a query, is the query set up for pessimistic locking?

The reason I am asking is that normally, Access forms are optimistic. They take a snapshot of the underlying record at/during the Form_Current event and at that point, the copy has an independent existence from the recordset. The things you are editing exist only in the controls of the form. They reconnect to the recordset when you are doing an Update operation through one of the normal ways of doing this.

Is there a chance that a sub-form is involved here? Because sub-forms interact with parent forms when relational integrity becomes an issue. But even for "normal" parent/child form cases, that seems a bit extreme.

 

[stevekos07]

You are correct that this seems to be unusual behavior. Access does this when you tell it to do something unusual. By any chance is the form set up for pessimistic locking? Or if this form is driven by a query, is the query set up for pessimistic locking?

The reason I am asking is that normally, Access forms are optimistic. They take a snapshot of the underlying record at/during the Form_Current event and at that point, the copy has an independent existence from the recordset. The things you are editing exist only in the controls of the form. They reconnect to the recordset when you are doing an Update operation through one of the normal ways of doing this.

Is there a chance that a sub-form is involved here? Because sub-forms interact with parent forms when relational integrity becomes an issue. But even for "normal" parent/child form cases, that seems a bit extreme.

The form was set to "Edited Records" locking. I have changed it to "No Locks" and I will see what happens. A conflict error isn't a problem, as it will be easy to resolve for this form.

 

[stevekos07]

Changing the locking option in the form seems to have worked! Cheers.

 

[The_Doc_Man]

Had to be something like that. Glad you found it.