recording changes

[sandrao]

I have a field called "TimeStamp" What I would like is that if someone
modifiys or make any change in the form that the "TimeStamp" will record
the time and date of change.

How can this be achieved?

sandrao

 

[Jeff Boyce]

In an event procedure in the form's AfterUpdate event, you could do
something like:

Me!txtYourTimeStampField = Now()

Note that if you use the BeforeUpdate event, every time your code changes
the value of this field, the form tries to update, the BeforeUpdate
(re-)triggers, and you "loop up" (at least, it seems to me I've seen
this...).

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[Ofer Cohen]

Assuming that you have a date type field in the table that linked to the form
(let say MyDate)

In the form BeforeUpdate event write the code

Me.[MyDate] = Now()


That will assign the date and time to the field when the record in the form
was updated.

Note: the BeforeUpdate event will fire even if the data in the field was
changed to the same value, it checking for changes in the form but it doesn't
check if the value was actually changed.

 

[Marshall Barton]

I have a field called "TimeStamp" What I would like is that if someone
modifiys or make any change in the form that the "TimeStamp" will record
the time and date of change.

Use the form's BeforeUpdate event to set the field:

Me.TimeStamp = Now

 

[sandrao]

I am not sure what the problem i but the time seem to change even if no
changes were made. Just tabing through the form results in the time changing
in the timestamp field.

Any other suggestions

 

[Ofer Cohen]

Do you have any other code behind the form (Like OnCurrent event) that might
change any other value in the form fields?

That will trigger the form BeforeUpdate event

 

[Bob Quintal]

In an event procedure in the form's AfterUpdate event, you could
do something like:

Me!txtYourTimeStampField = Now()

Note that if you use the BeforeUpdate event, every time your code
changes the value of this field, the form tries to update, the
BeforeUpdate (re-)triggers, and you "loop up" (at least, it seems
to me I've seen this...).

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

Jeff, the behaviour you describe is what happens in the AfterUpdate
event.Using the BeforeUpdate prevents this.

 

[rquintal]

In an event procedure in the form's AfterUpdate event, you could do
something like:

Me!txtYourTimeStampField = Now()

Note that if you use the BeforeUpdate event, every time your code changes
the value of this field, the form tries to update, the BeforeUpdate
(re-)triggers, and you "loop up" (at least, it seems to me I've seen
this...).

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

Jeff, the behaviour you describe is what happens using the AfterUpdate
event.Using the BeforeUpdate prevents this.

 

[John W. Vinson]

Jeff, the behaviour you describe is what happens in the AfterUpdate
event.Using the BeforeUpdate prevents this.

You're mistaken, Bob; Jeff is correct. It's counterintuitive but you must use
the AfterUpdate event to change the value in the control.

John W. Vinson [MVP]

 

[Bob Quintal]

You're mistaken, Bob; Jeff is correct. It's counterintuitive but
you must use the AfterUpdate event to change the value in the
control.

John W. Vinson [MVP]

I am NOT mistaken John, if you use the Form's after update event to
change a bound control on the form, you get locked into an endless
loop. You piqued my curiosity, so I built a test table, a form, and
added Me.ChangeStamp = Now() first in the before update event and
later the after update event. The after update event will not allow
leaving the record, maintains the pencil on the record selector, and
if you click the close button, "You cannot save this record at this
time."

 

[rquintal]

You're mistaken, Bob; Jeff is correct. It's counterintuitive but you must use
the AfterUpdate event to change the value in the control.

John W. Vinson [MVP]

I am NOT mistaken John, if you use the Form's after update event to
change a bound control on the form, you get locked into an endless
loop. You piqued my curiosity, so I built a test table, a form, and
added Me.ChangeStamp = Now() first in the before update event and
later the after update event. The after update event will not allow
leaving the record, maintains the pencil on the record selector, and
if you click the close button, "You cannot save this record at this
time."

Beswides, Marshal Barton an Ofer Cohen agree with me.

 

[Jeff Boyce]

Thanks, I never can get those straight. I end up using the "error and
trial" approach!

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[John W. Vinson]

I am NOT mistaken John, if you use the Form's after update event to
change a bound control on the form, you get locked into an endless
loop.

<blush> I'd gotten into my head that this was a *CONTROL'S* event, not a
forms. They work oppositely - you're quite correct about the Form event.

John W. Vinson [MVP]