After update property on a form 4

[jgarnick]

I have a form that has next and previous record command buttons on it so the user may scroll through a person's records. I also have 2 fields on the form that track who edits a record and when. In the after update property of the form, I set the fields to be equal to the user who is logged in and today's date. The problem is, if a user edits a record, then he/she can not go to the next record. The message says "Cannot go to the specified record. You may be at the end of a recordset." I've pinpointed that it is the updating of the fields that causes that error. Why is that, and how can I get around it? Thanks!

Below is the code I have in the after update property of the form:

Private Sub Form_AfterUpdate()
DATE_CHG = date
INIT_CHG = [Forms]![login]![User]

End Sub [sig]<p>jgarnick<br><a href=mailto:jgarnick@aol.com>jgarnick@aol.com</a><br><a href= > </a><br> [/sig]

 

[mdav2]

Do you have a field that the user must fill in?

If so you could populate the fields on the onchange() event for that field.

 

[jgarnick]

There is not a field that the user must fill in--they could edit any one of 30 different fields--

Thanks for your suggestion anyways-- [sig]<p>jgarnick<br><a href=mailto:jgarnick@aol.com>jgarnick@aol.com</a><br><a href= > </a><br> [/sig]

 

[THoey]

I am curious if it is modifying the existing record or adding a new record, this putting the pointer at the end of the file.

Also, Access's way of handling the record selectors is weird to say the least. I usually add the code from a book I have to create my own record selection process. [sig]<p>Terry M. Hoey<br><a href=mailto:th3856@txmail.sbc.com>th3856@txmail.sbc.com</a><br><a href= > </a><br>Ever notice that by the time that you realize that you ran a truncate script on the wrong instance, it is too late to stop it?[/sig]

 

[jagilman]

You make the following reference in your code

INIT_CHG = [Forms]![login]![User]

Is this form open and available to the code at this time?

[sig]<p>John A. Gilman<br><a href=mailto:gms@uslink.net>gms@uslink.net</a><br>[/sig]

 

[jgarnick]

Yes, the form is open--good thought anyways--

And I don't believe it is adding a new record--the fields do get edited, but you just can't go to the next record. When you edit a record in Access, does it consider that one record the recordset??

[sig]<p>jgarnick<br><a href=mailto:jgarnick@aol.com>jgarnick@aol.com</a><br><a href= > </a><br> [/sig]

 

[jagilman]

In a test I found this wont work! But it will if you use the before update event for the form. [sig]<p>John A. Gilman<br><a href=mailto:gms@uslink.net>gms@uslink.net</a><br>[/sig]

 

[jgarnick]

What won't work? Updating a field in the after update event? Using the before update doesn't make sense, because if the record is not updated, I don't want the fields updated.

It seems like you should be able to do this! [sig]<p>jgarnick<br><a href=mailto:jgarnick@aol.com>jgarnick@aol.com</a><br><a href= > </a><br> [/sig]

 

[PaulF]

Check this entry out in the Access Help File: BeforeUpdate, AfterUpdate Events
It explains when the events fire.

Another option open to you is the form's Dirty Property..... You can attach If Me.Dirty code to the move buttons and the form's OnClose event, to do the same thing.

PaulF
[sig][/sig]

 

[jgarnick]

I don't know what I was thinking --yes it does work with the before update property--thanks!! [sig]<p>jgarnick<br><a href=mailto:jgarnick@aol.com>jgarnick@aol.com</a><br><a href= > </a><br> [/sig]

 

[Guest_imported]

Probably you set up a loop: Update > field entry > Update > field entry etc.

 

[MichaelRed]

jgarnick,

You're probably already satisified w/ the results you have, so I will not elaborate. When I &quot;want&quot; to keep a history file, I set up a SEPERATE table for just the changes. On the data entry form, I check the 'dirty' flag in before update for every record change. If the form &quot;is Dirty&quot; I loop through all of the &quot;active&quot; controls checknig the old value against the current value. For each value changed, I log the user name, data/time, record ID, old value, current value, control name, rowsouce. These are all logged to the &quot;History&quot; table. No need for the user name/date info on the form.

If you want to keep a real track of &quot;Who shot John&quot; this is the approach. ---- But be aware that you probably want to have a routine to &quot;Purge&quot; the history file of info pertainig to Inactive records!!!! The history file will (rapidly) grow to be much larger than the &quot;live&quot; data file in user transaction intensive applications [sig]<p>MichaelRed<br><a href=mailto:mred@duvallgroup.com>mred@duvallgroup.com</a><br>There is never time to do it right but there is always time to do it over[/sig]