×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

After update property on a form
4

After update property on a form

After update property on a form

(OP)
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

jgarnick
jgarnick@aol.com

RE: After update property on a form

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.

RE: After update property on a form

(OP)
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--

jgarnick
jgarnick@aol.com

RE: After update property on a form

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.

Terry M. Hoey
th3856@txmail.sbc.com

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?

RE: After update property on a form

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?

John A. Gilman
gms@uslink.net

RE: After update property on a form

(OP)
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??  

jgarnick
jgarnick@aol.com

RE: After update property on a form

In a test I found this wont work! But it will if you use the before update event for the form.

John A. Gilman
gms@uslink.net

RE: After update property on a form

(OP)
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!

jgarnick
jgarnick@aol.com

RE: After update property on a form

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

RE: After update property on a form

(OP)
I don't know what I was thinking --yes it does work with the before update property--thanks!!

jgarnick
jgarnick@aol.com

RE: After update property on a form

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

RE: After update property on a form

2
jgarnick,

You're probably already satisified w/ the results you have, so I will not elaborate.  When I "want" 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 "is Dirty" I loop through all of the "active" 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 "History" table.  No need for the user name/date info on the form.

If you want to keep a real track of "Who shot John" this is the approach.  ---- But be aware that you probably want to have a routine to "Purge" the history file of info pertainig to Inactive records!!!! The history file will (rapidly) grow to be much larger than the "live" data file in user transaction intensive applications

MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close