as Neopa suggested... my thoughts on places to check.
Access does not "randomly" set values in records - upon creation of the record all field values are null unless and/or until something takes an action such as a default value.
So in order of thought:
Tables at design, the [Yes/No] fields have a default value of "No" (=== false) when initially added to the table. The most common habit is for people to change this value to "Yes" or delete the value... creating a null... which can have some really fun consequences for searches and if one pushes the record to a SQL-Server
Event in the form:
Despite the fact that the control button is running via macro vs vba... either the form's or the control's after_update event will still trigger once the record is pasted. Do we have any VBA or macro code at the form level that could potentially alter the value of the field.
Event at the table level:
I would dare say, that not many people know that this can be done in the newer versions of Access - the equivalent of a trigger for other databases. A macro can be created that either takes direct action itself or can call a VBA function. You would most likely know if you've done this, hence, why it's the last place I would look for such a Gremlin.
---
I've built a test database in an attempt to duplicate your experience; however, I am not able to do so with what I have done.
Please do me a favor,
Open the command button properties and show the macro editor.
select one row of the macro code, doesn't matter which, we just want the focus within the script.
Press <Ctrl><A> to select all
Press <Ctrl><C> to copy all
Come back to this thread
Click in the reply box and <Ctrl><P>
Select the pasted text and click on the [CODE/] format
You should get something like this (of course yours will have other commands ;-) ):
- <?xml version="1.0" encoding="UTF-16" standalone="no"?>
-
<UserInterfaceMacros xmlns="http://schemas.microsoft.com/office/accessservices/2009/11/application"><UserInterfaceMacro For="Command2" Event="OnClick"><Statements><Action Name="FindNextRecord"/></Statements></UserInterfaceMacro></UserInterfaceMacros>
don't worry about stepping the code one of us will take care of that when we review it.
What I am looking for is anything extra that the macro may be executing behind the scenes and this is the most sure way to check that there isn't an extra call being made.
---
On a side note:
Something I find a bit interesting is that you are making a duplicate record which tells me that you do not have a primary key set for this table... why are we duplicating record information? This then suggests that the database may not be normalized in that we're repeating the same information... there are certainly very valid reasons, say an event in a calendar or reoccurring sale of an inventory item to a customer (I could think of other ways and means to record this event).
4
