Tab Controls and Navigating Records

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Has anyone been able to distinguish the reason why when a tab control is
added to a form and a record is either added or edited, it will keep the form
in edit mode? This mode doesn't allow navigation to a next or previous record
or even a new record without adding:

Private Sub Field1_AfterUpdate()
Me.Refresh
End Sub

Isn't Access supposed to immediately save a record when moving to another
record or by adding a new record? Thanks!

(e-mail address removed)
 
My experience does not match what you describe. Whether the form is on a tab
page or not should not make a difference, and it should be necessary for use
a Refresh to force the save in the AfterUpdate of every control.

Something else must be at work here. Perhaps Name AutoCorrect is making
Access confused about what's going on. Uncheck the boxes under:
Tools | Options | General | Name AutoCorrect
More info on why:
http://allenbrowne.com/bug-03.html

Or perhaps you have multiple subforms that have the same table as
RecordSource, so you have interferring instances. This is particularly
noticeable with BLOB fields such as Memos. If this is the case, redesigning
the tables so there are fewer fields in the table and you have a correctly
normalized structure will help.

Or perhaps there is some code in an event that is preventing the record from
saving correctly.
 
Thanks Allen. I found what the problem was. While searching the Microsoft
knowledge base, I found a kb on creating a date created and date modified
field. In the example, it said to put on the Forms AfterUpdate the following
code:

me.datemodified = now()

The only problem is that whenever anything is changed on a record, it keeps
the record in edit mode and will not release it unless I add a piece of code
like this:

sendkeys "{ESC}", true

The problem with this is pretty obvious. If a data entry person activates
this piece of code from where ever I place it, it undo's whatever
changes/additions they've just made.

Do you know of a cleaner way of utilizing a date created and date modified
option?
 
Use the form's BeforeUpdate event, not AfterUpdate.

There is no point dirtying the record again as soon as it is saved, and that
does trigger an endless loop of updates until you have to cancel one.

Form_BeforeUpdate is perfectly safe: the date/time value is not written
unless the save succeeds, and it happens at the last possible moment before
the save.
 
Thanks, that works perfectly . . . (@¿@)

Allen Browne said:
Use the form's BeforeUpdate event, not AfterUpdate.

There is no point dirtying the record again as soon as it is saved, and that
does trigger an endless loop of updates until you have to cancel one.

Form_BeforeUpdate is perfectly safe: the date/time value is not written
unless the save succeeds, and it happens at the last possible moment before
the save.
Click to expand...
 
Back
Top