You are on page 1of 2

How to Stop Bound Forms from Updating Automatically Introduction.

A very common question we have here on Bytes relates to how bound forms update t he record data automatically when the focus is in any way moved away from the cu rrent record onto another, or new, record. In many instances this is required be haviour. It can make a form work similarly to reviewing data in a table grid. So metimes however, the designer feels that the users may make changes to the data stick (save them away) without being properly conscious of what they are doing, so requires a way of channeling such decisions through an explicit Save button. Below we will discuss the approach that can provide this facility. Form Design. Before we go much further let's go through the type of form we're dealing with a nd describe how it may be set up. First start with a bound form. For illustrative purposes we can create this from a table using the Create Form wizard. Simply select the table you're interested in then click on the New Object button. If the Form option isn't currently sele cted then use the drop-down facility to select it. From the wizard, add all the fields into the box on the right, then select the d efaults until prompted with the name of the form on the last page. Don't use the default name, as it will be the same as the table, which is very poor policy. W hen a name has been entered, select to modify design on completion. You will not ice (after Finishing) that the Record Source property is already set to the name of the table. This makes it a Bound form. This is a basic form for modifying th e table. Design Changes to Force Use of Save Button. The first change to make is to add the Save button itself. Easily done using the Toolbox (Available from Form Design toolbar). I suggest adding the button into the form's footer section. From the Command Button wizard select Record Operatio ns and Save Record. Use defaults or change as you will. I never advise leaving t he default names, so I've called mine cmdSave. Never mind about the code, as we' ll be changing that later anyway. The code to support this change is (Be sure to copy and paste this over whatever is there currently, allowing for the name you use for the Save Command Button.) : 1. Option Compare Database 2. Option Explicit 3. 4. Private blnGood As Boolean 5. 6. Private Sub cmdSave_Click() 7. blnGood = True 8. Call DoCmd.RunCommand(acCmdSaveRecord) 9. blnGood = False 10. End Sub 11. 12. Private Sub Form_BeforeUpdate(Cancel As Integer) 13. Dim strMsg As String 14. 15. If Not blnGood Then

16. Cancel = True 17. strMsg = "Please use the Save button to save your changes," & _ 18. vbNewLine & "or Escape to reset them." 19. Call MsgBox(Prompt:=strMsg, Title:="Before Update") 20. End If 21. End Sub The first two (Option) lines are (should be) in all modules. Line #4 sets up a persistent but private (to the form module) boolean variable t o indicate whether the save is due to a call from cmdSave or not. cmdSave_Click ensures blnGood is set True before attempting the save, then reset to False afterwards to ensure no other saves are flagged as good in error. Form_BeforeUpdate checks blnGood before proceeding. If True, then the save goes ahead normally. Otherwise Cancel is set to True (to stop the save) and a polite and informative message is sent to the operator to explain why, and how to conti nue. Conclusion. Although this is a common problem, particularly for newbies, this is very easy t o get around. This should never be cause for anyone to try to provide similar fu nctionailty via unbound forms, which is much more difficult and results in an un necessarily complex project. Unbound forms have their uses, but this is not one of them. 22. Jul 9 '10 #1

You might also like