Results 1 to 5 of 5
  1. #1
    Join Date
    Jul 2016
    Posts
    2

    Answered: Adding a new record to a table from a split form

    I am attempting to create a form that has the functionality to search and to add a record all in a split form. I have the 'Search' portion working well, as well as the 'Reset' and 'Print Records' buttons. I had all of it working perfectly with the record source being a table, except for the fact that when I added a new record, the fields that are not directly entered but inferred from the other data, were not updating. I have changed things around so many times now trying to get it to work. This is the simple code I had that was working when the source was a table. Below that is a screen shot of what the form looks like for further clarification. I do have data entry set to yes, as well as allow additions and no record locks. Any help would be great. Thank you.

    Code:
    Private Sub Command312_Click()
    On Error GoTo Command312_Click_Err
    
        On Error Resume Next
        DoCmd.GoToRecord , "", acNewRec
        If (MacroError <> 0) Then
            Beep
            MsgBox MacroError.Description, vbOKOnly, ""
                End If
    
    
    Command312_Click_Exit:
        Exit Sub
    
    Command312_Click_Err:
        MsgBox Error$
        Resume Command312_Click_Exit
    
    End Sub
    Click image for larger version. 

Name:	mdb screen shot.PNG 
Views:	6 
Size:	52.8 KB 
ID:	17058

  2. Best Answer
    Posted by Missinglinq

    "
    Quote Originally Posted by nrypka View Post
    ...This is the simple code I had that was working when the source was a table...
    So what is the Record Source now...a Multi-Table Query? Multi-Table Queries are frequently Read-Only, which is probably you problem. General rule of thumb is one Form/one Table.

    As for the code, itself, not really sure why you have reference to Marco Errors in VBA code (unless this was originally a Macro converted to code) but all you really need to go to a New Record, assuming that the Form isn't Read-Only, would be

    Code:
    Private Sub Command312_Click()
       DoCmd.GoToRecord , , acNewRec
    End Sub

    Also note that with Data Entry set to Yes, you can only enter New Records...you cannot view/edit existing Records! The Data Entry Property doesn't have to be set to Yes in order to enter New Records!

    Linq ;0)>"


  3. #2
    Join Date
    Feb 2004
    Location
    New Zealand
    Posts
    1,399
    Provided Answers: 5
    have you got the parent,child ID setup
    hope this help

    See clear as mud


    StePhan McKillen
    the aim is store once, not store multiple times
    Remember... Optimize 'til you die!
    Progaming environment:
    Access based on my own environment: DAO3.6/A97/A2000/A2003/A2007/A2010
    VB based on my own environment: vb6 sp5
    ASP based on my own environment: 5.6
    VB-NET based on my own environment started 2007
    SQL-2005 based on my own environment started 2008
    MYLE
    YOUR PASSWORD IS JUST LIKE YOUR TOOTHBRUSH DON'T SHARE IT.

  4. #3
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Quote Originally Posted by nrypka View Post
    ...This is the simple code I had that was working when the source was a table...
    So what is the Record Source now...a Multi-Table Query? Multi-Table Queries are frequently Read-Only, which is probably you problem. General rule of thumb is one Form/one Table.

    As for the code, itself, not really sure why you have reference to Marco Errors in VBA code (unless this was originally a Macro converted to code) but all you really need to go to a New Record, assuming that the Form isn't Read-Only, would be

    Code:
    Private Sub Command312_Click()
       DoCmd.GoToRecord , , acNewRec
    End Sub

    Also note that with Data Entry set to Yes, you can only enter New Records...you cannot view/edit existing Records! The Data Entry Property doesn't have to be set to Yes in order to enter New Records!

    Linq ;0)>
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  5. #4
    Join Date
    Jul 2016
    Posts
    2
    You were correct Missingling it was because I had it set to a Multi-Table query

  6. #5
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Glad you got it sorted!

    Linq ;0)>
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •