Results 1 to 14 of 14
  1. #1
    Join Date
    Jul 2009
    Posts
    185

    Question Unanswered: Can I creat a save Comand Button

    I would like to give my user a "Save" button. I have a Access 97 that shows adding a button but Access 200& 2003 doesn't seem to have the same function.

  2. #2
    Join Date
    Jul 2009
    Posts
    185
    I have found this line but I still can't fiqure out how to use it.I have search the net but I don't understand what it does.

    DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70

  3. #3
    Join Date
    Mar 2009
    Posts
    5,442
    Provided Answers: 14
    Try this:

    If Me.Dirty = True then
    Me.Dirty = False
    End If

    See: Microsoft Access Flaws - Losing data when you close a form

    Have a nice day!

  4. #4
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Sinndho's code is fine or you can use

    DoCmd****nCommand acCmdSaveRecord

    or even the code you listed. That code is simply calling the "Save" function from the menu and is the code the Command Button Wizard generates for this task. The code simply goes in the Click event of a command button.

    You are aware, are you not, that moving to another record or simply closing the form, using the native Access "Close" button, will automatically save the record in Access?

    Be sure to go to the link Sinndho gave to learn about forcing a save defore closing a form using DoCmd.Close.
    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. #5
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Why do you think you need one? I ask because there are different reasons people ask for this and the answer guides the solution.

    Choices:

    (1) Let Access autosave data as they go and just add an almost irrelevant command button "Save" the current record's data

    or

    (2) Prevent saving until a condition is met, such as an Allow Saving option button.

    or

    (3) Use unbound forms with a true Save button with coded retrieval and storage.


    I think you need to decide very carefully what you want to do here before going any further.

    And PLEASE, for the love of God and all things holy, don't use DoMenuItem. EVER.

    DoCmd.PunCommand accmdSaveRecord does exactly the same thing and is a whole lot more developer friendly. That red P should be an R, but this forum is a bit stupid and trashes anything with dot-r-u in it.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  6. #6
    Join Date
    Mar 2009
    Posts
    5,442
    Provided Answers: 14
    You are aware, are you not, that moving to another record or simply closing the form, using the native Access "Close" button, will automatically save the record in Access?
    @ Missinglinq:
    Precisely not, it's a bug in Access. See Allen Brown's warning about that at:
    Microsoft Access Flaws - Losing data when you close a form

    @ StarTrekker:
    100% with you about that.

    Have a nice day!

  7. #7
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    Precisely Yes, Sinndho! The statement is correct if you use the native Access Close button, which is to say the big X in the upper right-hand corner of the form, as I said in my post.

    If you use a custom close button using DoCmd.Close and there is one or more fields that fail validation, you will, indeed encounter a problem, which is why, if you look at the next line of my post, you'll see that I urged the OP to go to the link you provided to learn about this bug!

    Be sure to go to the link Sinndho gave to learn about forcing a save defore closing a form using DoCmd.Close.
    Hope this helps!

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

    All posts/responses based on Access 2003/2007

  8. #8
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    My God Microsoft are pathetic. Sindho posted a link about Access Flaws. I didn't even know this flaw existed, but I find it highly retarded that Microsoft have not only FAILED to fix this error in service packs, but the error STILL EXISTS in version 2007.

    What is wrong with them?... why would they not fix this?! Are they deliberately trying to piss everyone off?
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  9. #9
    Join Date
    Aug 2009
    Posts
    12
    Quote Originally Posted by StarTrekker
    (2) Prevent saving until a condition is met, such as an Allow Saving option button.
    How do I do this? I want it so that closing the form doesn't save anything, rather a button must be pressed in order for the record to be saved.

    (I want it so that if i close the form without pressing a "save" or "submit" button, the information that I had entered on the form will be lost. This seems to make more sense to my end users, who are used to pressing a button to save stuff.)

    I've been trying to figure out how to make my form work this way.... help please

  10. #10
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    This code will do it:
    Code:
    Dim SavedFlag As Boolean
    
    Private Sub Form_Current()
      SavedFlag = False
    End Sub
    
    Private Sub SaveButton_Click()
     SavedFlag = True
     If RecordsetClone.RecordCount > 1 Then
     DoCmd.GoToRecord , , acNext
     DoCmd.GoToRecord , , acPrevious
     End If
    End Sub
    
    Private Sub Form_BeforeUpdate(Cancel As Integer)
     If SavedFlag = False Then
      Me.Undo
     Else
      SavedFlag = False
     End If
    End Sub
    You need to make sure all users understand that standard Access behavior is no longer in play! An experienced Access user would be very ticked off to enter an hour's worth of records, moving from one new record to another, assuming the default Access behavior was in play, only to find out that none of the records were saved!

    As to StarTrekker's

    "I find it highly retarded that Microsoft have not only FAILED to fix this error in service packs, but the error STILL EXISTS in version 2007."

    And your point would be? Mouse wheels have been around for ages, and Microsoft just got around to addressing their scrolling thru records with 2007!

    And while the bug still exists in 2007, they at least did add (or so I'm told) the line

    If Me.Dirty Then Me.Dirty = False

    before the line

    DoCmd.Close

    in the code the Command Button Wizard generates for a form close button!

    OF course, this generated a new bug! IF you use the Wizard to generate a form close button for an unbound form, it errors out because of the reference to Dirty, which isn't a valid property of an unbound form!!
    Hope this helps!

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

    All posts/responses based on Access 2003/2007

  11. #11
    Join Date
    Aug 2009
    Posts
    12
    Can you make the code work so that the button will save AND move to the next blank record?

    sorry - i'm a rookie here!

    Quote Originally Posted by Missinglinq
    This code will do it:
    Code:
    Dim SavedFlag As Boolean
    
    Private Sub Form_Current()
      SavedFlag = False
    End Sub
    
    Private Sub SaveButton_Click()
     SavedFlag = True
     If RecordsetClone.RecordCount > 1 Then
     DoCmd.GoToRecord , , acNext
     DoCmd.GoToRecord , , acPrevious
     End If
    End Sub
    
    Private Sub Form_BeforeUpdate(Cancel As Integer)
     If SavedFlag = False Then
      Me.Undo
     Else
      SavedFlag = False
     End If
    End Sub
    You need to make sure all users understand that standard Access behavior is no longer in play! An experienced Access user would be very ticked off to enter an hour's worth of records, moving from one new record to another, assuming the default Access behavior was in play, only to find out that none of the records were saved!

    As to StarTrekker's

    "I find it highly retarded that Microsoft have not only FAILED to fix this error in service packs, but the error STILL EXISTS in version 2007."

    And your point would be? Mouse wheels have been around for ages, and Microsoft just got around to addressing their scrolling thru records with 2007!

    And while the bug still exists in 2007, they at least did add (or so I'm told) the line

    If Me.Dirty Then Me.Dirty = False

    before the line

    DoCmd.Close

    in the code the Command Button Wizard generates for a form close button!

    OF course, this generated a new bug! IF you use the Wizard to generate a form close button for an unbound form, it errors out because of the reference to Dirty, which isn't a valid property of an unbound form!!

  12. #12
    Join Date
    Aug 2009
    Posts
    12
    I think I figured out how to do it. Can someone double check this code for me? I've bolded the part below that I modified - to make it work so that pressing the button saves the record and moves it to the next new record.




    Option Compare Database

    Dim SavedFlag As Boolean




    Private Sub Cancel_Button_Click()
    On Error GoTo Err_Cancel_Button_Click


    DoCmd.DoMenuItem acFormBar, acEditMenu, acUndo, , acMenuVer70

    Exit_Cancel_Button_Click:
    Exit Sub

    Err_Cancel_Button_Click:
    MsgBox Err.Description
    Resume Exit_Cancel_Button_Click

    End Sub

    Private Sub Form_Current()
    SavedFlag = False
    End Sub

    Private Sub SaveButton_Click()
    SavedFlag = True
    DoCmd.GoToRecord , , acNewRec


    End Sub


    Private Sub Form_BeforeUpdate(Cancel As Integer)
    If SavedFlag = False Then
    Me.Undo
    Else
    SavedFlag = False
    End If
    End Sub

  13. #13
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    No way that I know. When you start tinkering around with Access, trying to make it stop working in the way it's designed to work, you sacrifice things.

    Maybe some one else has a hack where you can do both, but every one I've ever seen works exactly like the code I've given you.

    Quote Originally Posted by emwa
    i'm a rookie here!
    This statement is exactly why you really should listen to experienced developers, especially when they tell you that something is a bad idea, such as having a "Save" button, as if it's a word processing program.

    There are two main points that have made MS Access such a large part of the database market.

    1. It allows for the very rapid development of relatively complicated databases
    2. Users of one Access database basically know how all Access databases work


    It's this second trait that has really made it popular with users and the employers of users, because the learning curve is greatly reduced, thus training time is decreased as are training costs. Programming Access to work in a manner other than it's standard way does just the opposite.
    Hope this helps!

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

    All posts/responses based on Access 2003/2007

  14. #14
    Join Date
    Aug 2009
    Posts
    12
    I can understand your point, but that doesn't apply for these users. I'm creating this database for people who primarily use applications where they must press a save button in order to save - they won't likely be using any other access applications. So in this case, this actually makes it less confusing for them. Trust me, i'd rather leave it as is, but for the weird looks i keep getting when i try to explain how access works - they don't come from that background. (and to be honest, neither do i)

    Plus, I'm providing a training manual for them, so anyone that does use access will know up front how I'm setting this up for them.

    thanks for your help anyways, i've tested the form and it seems to work with your code and my changes, so I think i'll stick with it. If it messes up, i can always change it back

Posting Permissions

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