Help to confirm if a bug (or not).

[245]

Help to confirm if a bug (or not)

We need help to confirm whether what is described herein is a bug, or something that we are doing incorrectly. If it is a bug, please report as needed. In either case please help us with a resolution without using a lot of VBA which we have not yet learned.

Short version: (yeah right)

Two separate forms for their respective (separate) tables; not related. Each have their own timestamp field/column with different names. Using the following snippet, one (1) of these forms works flawlessly, while the other (form) exhibits intermittent behavior. After the database remains open and idle, and/or, if the machine goes to sleep (not hibernate) then awakens -- attempting to enter a new record using the problematic form, associated table or code, the AFTER_UPDATE() or the DONE_CLICK() -- will not initiate/execute the "Me!DATE_ENT = Now()" <-- after we use the date picker then move to the next field, or single left-click the button-control .

Private Sub DATE_ENT_AfterUpdate()
Me!DATE_ENT = Now()
DoCmd.RunCommand acCmdSaveRecord
DoCmd.Requery
End Sub



Private Sub DONE_Click()

End Sub

NOTE: we have used the above code in AfterUpdate() or in DONE_Click with the same ill (intermittent) results.

The above code works flawlessly in either of the above events on 'form-1' and intermittently, regardless of what event, on the other 'form-2'; as previously stated.

This next description appears to be associated with the above, however you cannot see it while it happens, it takes place behind the scenes:

· Access has been open and machine idle; playing movies for approximately four (4) hours or more.
· Time to use access and enter a record. Once at the timestamp field, the user chooses 'today' from the date-picker (m/dd/yyyy), then uses the <tab-key> or mouse-click away from the field -- and the above "Me!DATE_ENT = Now()" does not execute within the field it is assigned to; leaving the user to think the code is broken.

After further review, we find that 'Access 2007' appears to have placed the results of "Me!DATE_ENT = Now()" in the immediate previous record for the same field, deleting the timestamp that was originally there; all the while the newly created record was entered correctly minus the results of " Me!DATE_ENT = Now()" which as stated earlier went to a previous records timestamp.

I don't see how we could have made a user error on this, given that we are using the same code within different form and this only happens with form-1.datefield and its associated table.datefield and not form-2. etc, etc.

Please help us to confirm, if at all, this is a 'BUG' or if in fact we have done something incorrect. When explaining please proceed slowly.

Thank you all for reading.

[RuralGuy]

Verify what I am seeing for me please. You are modifying the value of the DATE_ENT field in the AfterUpdate event of a control that is probably bound to that same field. Is that correct?

[245]

Verify what I am seeing for me please. You are modifying the value of the DATE_ENT field in the AfterUpdate event of a control that is probably bound to that same field. Is that correct?

You are absolutely correct. The field is being updated via the 'AfterUpdate' event, after we choose &quot;Today&quot; from the date-picker. This problem just happened again. :-\

[RuralGuy]

If the control is bound to this DateTime field (DATE_ENT) then it is already being updated when you make the selection in the Date Picker. Why do you feel you need to do it again in the AfterUpdate event of the same control?

[245]

The goal of the 'AfterUpdate' event for the field in question (DATE_ENTERED) is an after thought, as we are learning. We initially created the DATE_ENTERED field with just the date-picker. We then saw that the 'picker' would allow a user to falsify the actual date entered, hence we found the 'AfterUpdate' event and thought , "this is cool" and it works everywhere but in this one (1) form and it's associating table. Of course we can just automagically put the date without user interaction, but, once we stumbled on to this we stopped, until we could get a handle on exactly why this is working for one (1) form and table yet not 'this' other particular form in question.

[RuralGuy]

You only get an AfterUpdate event if the user changes the value in the control. If you do not want the user to be able to fudge this date then don't even let them see it. Just update the field in the BeforeUpdate event of the FORM just as you would with any DateTime stamp of a record. I have no idea why you are getting different results but the approach would be much better if you use my suggestion.

[245]

Your suggestion is noted and appreciated, however the timestamp must be the final piece of data entered into the record, hence the 'BeforeUpdate' event would result in the 'time' being just a tad off. It is annoying that not only are we getting varying results using the same code in the same events using different forms and tables but, when this happens -- i.e. the Me!DATE_ENT = Now() results are found to delete and replace the contents of the DATE_ENT field for the previous record instead of placing the results of Now() in the current record.

[RuralGuy]

You do know that the FORM BeforeUpdate event occurs as the record is being updated, right? Updating the bound field of a control in the AfterUpdate event of that same control is simply not a good practice. My suggestion would work under all cases and it appears that your practice has varying results. It is your system and you are free to do as you choose. I simply offer a suggestion.

[245]

We understand what you are saying, but we are still trying to understand, why and/or what is taking place that makes the result of this code: Me!DATE_ENT = Now() end up in the proper field in the previous record and not the current record being created/entered. :-) Once again, we are aware there is more than one (1) way to work around this, but the fact/question remains is this a bug or improper usage? --Given that this is only happening with one (1) of our forms and its associating table and not, the other form and its associated table. We would like to know. :-)

[RuralGuy]

Without knowing more about your form I doubt I can have any useful suggestions. I see nothing in the code that would alter the "previous" record unless you are currently *not* on the record you think you are.

[245]

Perhaps it would be better served if we provide a copy of the database in all of its crude glory; quite ugly from a professional view. We don't want anyone to 'work' and fix our wrong doing; would only like to know if this is an Access problem 'bug' or not. That said, if you are willing to take a look, we will --saveas- the database, delete our data then provide the structure for all to see; and laugh if you choose to do so. :-)

[RuralGuy]

You can create a new db and *import* everything *but* the data to get the sample. Then zip it up and post and I'll find some time to look at it.

[RuralGuy]

Here's pictures on how to do that if you need them. http://www.btabdevelopment.com/ts/impnew

[245]

The attached is not a result of following your directions. I did a 'save as' and deleted everything that did not 'seem' to be associated the issue at hand. You will see there are some subforms missing (deleted) along with most of the personal data. I guess the idea here is for you to see all of the configuration and/settings.

Thank you for taking the time to review. :-)

BTW, as a temporary work around, we opted to auto enter the date/time and disabled the field within the form (grayed). We still want to know if what we initially wrote about is something we have done incorrectly or, have we stumbled on to an 'Access 2007" concern.

[RuralGuy]

Did you verify that your sample demonstrates the problem?