Form doesn't clear when adding new record

[bigalpha]

Created a button through button wizard that is supposed to open a form to add a new record, but all of the fields don't clear out. Only some fields clear and other fields actually populate data from another record.

Snip1 shows my form with a record selected. When I click the 'New Waste' button, you can see that the record ID goes to '(New)', but the fields actually populate data from another record.

This even happens if I set 'Data Entry' to yes for the form.

here's the code behind my button:

Private Sub btnNewWaste_Click()
DoCmd.GoToRecord , , acNewRec
End Sub

I even commented out my code for duplicating my record just in case but that didn't make a different.

Private Sub btnDuplicateRecord_Click()

Dim ctrl As Control

For Each ctrl In Me.Form.Controls
If ctrl.Tag = "DefaultMe" Then
ctrl.DefaultValue = """" & ctrl & """"
End If
Next ctrl

blndefault = True

DoCmd.GoToRecord acForm, Me.Name, acNewRec

End Sub

edit: this problem persists in a backup database that only contains one test record. The button pre-populates data that doesn't exist in the back-up database.

 

[bigalpha]

So I figured out the problem but not the solution.

If I click the 'duplicate' button it works as intended. however, if I decide I don't actually want to duplicate the data I have a 'back button' that exits the new record and just goes back to previous record.
Back button code:

If Not (Me.NewRecord) Then
    Me.Undo
End If

DoCmd.GoToRecord , , acPrevious

Then when I try to insert a new record after this, the data from the previously canceled duplicate entry is still populated.

I can't figure out how to clear the data out of the 'new record' entry. I assume it's because I'm not explicitly flushing the data.

 

[gemma-the-husky]

because the first statement is not doing anything. you go to a new record - but your first statement specifically undoes edits on existing records, not new records

see edit below

 [B]If Not (Me.NewRecord) Then
    Me.Undo[/B]
 [B]else[/B]
 [B]   [COLOR=sienna]msgbox("new record - no action processed")
[/COLOR]End If[/B]

DoCmd.GoToRecord , , acPrevious

 

[bigalpha]

because the first statement is not doing anything. you go to a new record - but your first statement specifically undoes edits on existing records, not new records

see edit below

 [B]If Not (Me.NewRecord) Then
    Me.Undo[/B]
 [B]else[/B]
 [B]   [COLOR=sienna]msgbox("new record - no action processed")
[/COLOR]End If[/B]

DoCmd.GoToRecord , , acPrevious

That's the 'back button' code.

The code for the duplicate button is in post #1.

 

[JHB]

..
Snip1 shows my form with a record selected. When I click the 'New Waste' button, you can see that the record ID goes to '(New)', but the fields actually populate data from another record.
... this problem persists in a backup database that only contains one test record. The button pre-populates data that doesn't exist in the back-up database.

I think the default values property for the controls isn't empty.
Open the form in design view and have a look in each control.

 

[bigalpha]

I think the default values property for the controls isn't empty.
Open the form in design view and have a look in each control.

You're right, the default values isn't getting cleared out. I assume that the correct path forward is to have the 'back/cancel' button clear those out. Is that right?

 

[JHB]

It depend on why you are setting the default value and where you use them.
I would start by removing them in the form design view, save the form afterwards, maybe that is enough.

 

[bigalpha]

I assume the default value is getting set when I attempt to duplicate the record via button.

If I click 'go back/cancel' or when I click 'new record' the default values are not cleared at any time.

The default values change based on which record I select in my search form.

This used to work perfectly when it was located in the main form. I moved this into a subform and now they don't work all the way correctly.

Duplicate Record Code

Private Sub btnDuplicateRecord_Click()

Dim ctrl As Control

For Each ctrl In Me.Controls
If ctrl.Tag = "DefaultMe" Then
ctrl.DefaultValue = """" & ctrl & """"


End If
Next ctrl

blndefault = True

DoCmd.GoToRecord , , acNewRec
' DoCmd.GoToRecord acForm, Me.Name, acNewRec

End Sub

Go Back / Cancel Code

Private Sub Command81_Click()

If Not (Me.NewRecord) Then
    Me.Undo
End If

DoCmd.GoToRecord , , acPrevious

End Sub

 

[gemma-the-husky]

So I figured out the problem but not the solution.

If I click the 'duplicate' button it works as intended. however, if I decide I don't actually want to duplicate the data I have a 'back button' that exits the new record and just goes back to previous record.
Back button code:

If Not (Me.NewRecord) Then
    Me.Undo
End If

DoCmd.GoToRecord , , acPrevious

Then when I try to insert a new record after this, the data from the previously canceled duplicate entry is still populated.

I can't figure out how to clear the data out of the 'new record' entry. I assume it's because I'm not explicitly flushing the data.

I said this already. The code in the back button does not undo a new record. it just leaves it as a record.

a form in data entry mode still has multiple records, but just the records for this editing session - so I think you are moving to a new record, and entering some data (maybe by copying) - but it is still a new record. When you then click "back" and move previous, you do not undo this record, [because your code specifically does not undo new records] but moving off the record does cause it to be saved as is. So when you come back to it by moving forward, you then return to this record, but it is not now a new record any more. However "undoing" this record now will just undo changes you make the next time you edit it. It will not delete the record completely.

I hope this makes sense

 

[bigalpha]

I said this already. The code in the back button does not undo a new record. it just leaves it as a record.

Sorry, I guess I misunderstood your first post. Sorry!

a form in data entry mode still has multiple records, but just the records for this editing session - so I think you are moving to a new record, and entering some data (maybe by copying) - but it is still a new record. When you then click "back" and move previous, you do not undo this record, [because your code specifically does not undo new records] but moving off the record does cause it to be saved as is. So when you come back to it by moving forward, you then return to this record, but it is not now a new record any more. However "undoing" this record now will just undo changes you make the next time you edit it. It will not delete the record completely.

I hope this makes sense

Yes, this makes sense. I did not realize that access worked in this fashion.

So what type of code should I research to revert the 'new record' to an actual new record?

 

[gemma-the-husky]

ok - unlike word or excel, say changes to database records are saved automatically in many ways.

it is not necessary to add a "save record" button. Even if you do, there are probably ways to save the record without clicking the button.

you can save the record with menu bar/ribbon options - or you can move to a new record, click the pencil in the record selector, or even close the from.

-----
a new record is a sort of temporary edit that may or may not be accepted by the database. If it is not accepted, it can be "undone", and no trace of it remains. Once it is accepted it is no longer a new record. You cannot now "undo" it at all. Instead you now have to "delete" it, to get rid of it.

----
What you do is
a) make some fields "required" so that if they are not entered, the record will not save AND/OR
b) add validation to your form in the before update event. You can check and specify any part of your data, and prevent the record updating if you are not happy with it.

it's a matter really of accepting that your users know what they are doing, but guiding them in areas where they need guidance.

----
just one other thing - if you are using autonumbers, bear in mind that starting a record entry, and then changing your mind "burns" the autonumber. Autonumbers should not be used to maintain an intact sequence, so it shouldn't be an issue, but many users still try to manage intact sequences with autonumbers.