Distribute ACCDE files. NOT ACCDB. They they cant access design or VBA!

You can also hide warning messages in the settings but recommend the above preferably

The screenshot below shows how I deal with this particular situation.

Hi Kevin, that's great I'll give it a shot!

Hi Dan, sorry to be a pain I'm not the brightest when it comes to this stuff. How would i go about creating a ACCDE file is it just as simple as saving as the file?

Did you watch the video Dan shared? Click on the link.

ACCDE :)

BTW, kudos on the design - that looks much better than anything I've made :P

Didn't realise that was link! haha. Oh thanks it's only taken me 3 years and about 300 Richard Rost videos to get this far haha.

Kevin's method is best, however you can also use some quick and dirty error handling to have Access ignore errors like that. An On Error Resume Next works wonders, but use it sparingly. See Error Handling

Hi Chris, consider greying out your button when there is no next record to go.  That's how the built-in buttons on Access forms do it (see pictures below).  If the user can't click the button, there won't be a run-time error to worry about.

Excellent idea.

I just implemented Kevin Yip's idea into my test database.
Here's the code I used:

Private Sub EnableDisableNavButtons()

    If Me.Recordset.RecordCount = 0 Then
        btnGotoNext.Enabled = False
        btnGotoPrevious.Enabled = False
    ElseIf Me.CurrentRecord = 1 Then
        btnGotoPrevious.Enabled = False
        btnGotoNext.Enabled = True
    ElseIf Me.CurrentRecord = Me.Recordset.RecordCount Or Me.NewRecord Then
        btnGotoNext.Enabled = False
        btnGotoPrevious.Enabled = True
    Else
        btnGotoNext.Enabled = True
        btnGotoPrevious.Enabled = True
    End If

End Sub

I called this sub in the On Current Event

The record count can change due to filters, requeries, etc., and it doesn't get updated until you move to another record and trigger Current event again.  So if you want the effect to occur instantly, .RecordCount may not help.  I would use the .EOF property to check if the current record is the last record.  .EOF only becomes True if you run .MoveNext while on the last record.  And you can't use .MoveNext on the Form.Recordset object because that will affect the form itself.  So you need to use the Form.RecordsetClone property instead, and you need to "sync" its record pointer to Form.Recordset object's record pointer.  My sample code is pictured below.

Having done that, there are still caveats to deal with.  Even if the final record is reached, the next record is still available -- the *new* record, if the form allows record additions.  In that case, the "next record button" should still be enabled.  That's why the Access built-in button is not disabled even if you are at the last record in this case.  RecordCount and EOF properties will not help you in this case.  Maybe the AllowAdditions property can, but I haven't tested.

That's why I usually would just rely on the built-in record buttons instead, in order to save me potentially a lot of work.  P.S.  In my old job, I used mostly unbound forms, removing the prev/next buttons altogether.

Just a small point.  In my code above:

     Not (x = 1)

is not the same as:

     Not x = 1

Richard may want to make a video on how important parentheses are (may already have).