Generic Form with "Save", "Cancel" buttons

[moi]

I am a beginner. and i am searching a demo form with 2 buttons (Save, Cancel). Reason is, i don't want the data being entered to automatically save into table.. can someone please help me.. thank you in advance..

 

[Edgar_]

i don't want the data being entered to automatically save into table

you could unbind the form or handle many events, have you tried something?

 

[Gasman]

Reason is, i don't want the data being entered to automatically save into table

Why?
You can prevent any bad data with the BeforeUpdate event of the form.

Perhaps review a few videos?

https://www.youtube.com/results?search_query=access+unbound+form+

 

[KitaYama]

I would never suggest an unbound form if there's some other way to do the same task, specially to someone who is new to Access.
I would set the Cycle property of the form to current record, add save and undo buttons and use OnClose event to undo before closing if the form is dirty.
User should either save the record or exit without saving.

 

[jdraw]

moi,
Welcome to AWF.
What exactly do you mean by "automatically"? You wouldn't Save bad data, so you validate the entered data, then either reject or save the data based on your validation. As Gasman says-- use the BeforeUpdate event of the form to do your validation. See this post for similar information.

Since you are a self-identified beginner, I suggest you describe your proposed application to readers and get some feedback. Do some research on various topics -reading posts, watching videos, analyzing sample databases...

Access does many things for you behind the scenes; better to learn and use these features than try to struggle with additional work.

 

[Edgar_]

I would never suggest an unbound form if there's some other way to do the same task, specially to someone who is new to Access.
I would set the Cycle property of the form to current record, add save and undo buttons and use OnClose event to undo before closing if the form is dirty.
User should either save the record or exit without saving.

I understand your concerns, but I would certainly not discard unbound forms considering all the measures one must program against the save-that-record-no-matter-what default behavior of Access. You have gracefully described some of the things one must counter when using the bound form.

Since an unbound form can be as simple or as complicated as:
if edit: load the data into the form
if new: load empty form
if save: validate and save

I would advice OP to consider the two approaches and explore what it's like to develop with the two possibilities.

 

[CJ_London]

you can use ADO disconnected recordsets which is fine for adding new data, but a real pain if the user can edit existing data as you will need routines to check whether someone else has edited or deleted the record before updating.

Advantage - you can bind the form to the ado recordset., particularly useful for a continuous form.

Disadvantage - some form functionality does not work with ADO, primarily sort and filter, although you can write your own alternatives to overcome this.

 

[Pat Hartman]

considering all the measures one must program against the save-that-record-no-matter-what default behavior of Access.

I guess you haven't viewed any of my videos on the topic.

If you understand how forms work, there is one and only one event you have to work with and that is the form's BeforeUpdate event. That event is like the flapper on a funnel. It is the last event that fires before a record gets saved. Therefore, your validation code goes there - or is called from there if you prefer - and you cancel the event if an error is discovered.

How hard is?

Cancel = True

 

[Pat Hartman]

Reason is, i don't want the data being entered to automatically save into table.. can someone please help me.. thank you in advance..

Then you need to understand how form events work. You are in total control over whether or not a record gets saved as long as you put your code in the correct event. Using an unbound form because you don't understand how form events work is like using a bazooka to shoot flies. YOU have to reproduce much of the code that MS already wrote for you in the code behind a form. There are reasons to use unbound forms but not because you don't know how to control if a record gets saved or not. See my response to Edgar. You also might want to view one or more of the videos at this link and then download the sample database so you can test for yourself.

Bad Data is Bad for Business #1 and #2

I just added #2 --- that link is further down. It is much shorter than #1. I also added a copy of the database I used for the video. Enjoy:) I created a database to help people to understand how and why to use the Form's BeforeUpdate event to validate data. @Uncle Gizmo and I made a...

www.access-programmers.co.uk

 

[Edgar_]

I guess you haven't viewed any of my videos on the topic.

If you understand how forms work, there is one and only one event you have to work with and that is the form's BeforeUpdate event. That event is like the flapper on a funnel. It is the last event that fires before a record gets saved. Therefore, your validation code goes there - or is called from there if you prefer - and you cancel the event if an error is discovered.

How hard is?

Cancel = True

That is correct, Pat, in the case of bound forms, you have to use the BeforeUpdate event and set its Cancel parameter to True to prevent the update programmatically. In the case of unbound forms, you do not require this event.

 

[Pat Hartman]

OK, so you need validation logic regardless of which path you choose, right? The validation is the same regardless of whether the form is bound or unbound.

But, with the unbound form, you need to control loading the form, scrolling, deciding when to save, and saving and you think using:

"Cancel = True" is a burden? You'd rather write potentially hundreds of lines of code than 1? OK.

I understand your concerns, but I would certainly not discard unbound forms considering all the measures one must program against the save-that-record-no-matter-what default behavior of Access.

I'm trying very hard to figure out why "Cancel = True" Is so burdensome that you would recommend an unbound form to a novice. Because "Cancel = True" is all you have to do to get Access to NOT save a record with invalid data, provided of course you know what event to use for validation. There are reasons for using unbound forms but not because you don't know how bound forms work.

If you put your validation in random events because you don't understand how events work, then you could literally have THOUSANDS of lines of validation code and not be able to stop bad data from being saved. I once removed FIVE THOUSAND lines of code from a single application that was saving bad data consistently. NONE of the validation code (5,000 lines of it) was stopping ANY bad data from being saved. Why? none of it was in any forms' BeforeUpdate event. It was in pretty much every other form event including AfterUpdate which runs AFTER the bad data has been saved plus in all the control events. So the same validation for DOB for example was repeated in 5 events for the DOB control. It was also repeated in 120 other controls (5 events each). So every control on the form had validation for every other control on the form in 5 events, and also had the same code in multiple form events. And nothing was working. Can you imagine how frustrated this programmer was? And he never figured out the right event to use so all three applications he built for this client had to have a few thousand lines of code removed from each and then simply moving ONE set of validation code to the form's BeforeUpdate event was all that was needed and solved the problem completely.

 

[MajP]

As @Pat Hartman says it is extremely simple to do this. For a simple form in single form view.

Private SavedOnPurpose As Boolean
Private Sub cmdCancel_Click()
  If Not Me.Dirty Then
    MsgBox "There are not updates to cancel.", vbInformation, "No Updates"
  Else
    MsgBox "Updates canceled.", vbInformation, "Updates Canceled."
  End If
    Me.Undo
End Sub

Private Sub cmdClose_Click()
  DoCmd.Close acForm, Me.Name
End Sub

Private Sub cmdSave_Click()
  SavedOnPurpose = True
  Me.Dirty = False
  MsgBox "Record Saved", vbInformation, "Saved"
End Sub

Private Sub Form_BeforeUpdate(Cancel As Integer)
  Dim rtn As Long
  If Not SavedOnPurpose Then
    rtn = MsgBox("Do you want to Save this record?", vbYesNo, "Save Record?")
    If rtn = vbNo Then
      Cancel = True
      Me.Undo
    End If
  End If
  'Reset
  SavedOnPurpose = False
End Sub

Where it gets tricky is when people want to do weird things like Create multiple records on a continuous form and then roll those back. Or Not create a parent record if you do not create child records.
Most of the time these are IMO just dumb user interface designs.
As @Edgar_ points out you have to account for all of the things that could make the form try to save (close, move to new record). That is why even though I have save / cancel buttons I still need to prompt to save/cancel in the before update.

If curious I included an example where you can add multiple records and roll them back in a transaction. Not something I would do, but it shows it can be done.

 

[Gasman]

@MajP
Any chance of getting the Transacted DB in the same format as the SimpleSave DB please?
I can open the latter, but not the first, unrecognized DB, as I am on 2007.

 

[MajP]

@Gasman,
Better yet, I will provide the Class to show you can turn any form into a transactional form.
1. Import class into VBE using the File Import.

2. On any form add the following buttons

Save Add
Save Edit
Save Close
Close (No Save)

3. Code on form
Do not give the form a Recordsource, but pass it in instead. Pass in the buttons.

Dim tForm As clsTransactedForm

Private Sub Form_Close()
    Set tForm = Nothing
End Sub

Private Sub Form_Open(Cancel As Integer)
    Set tForm = New clsTransactedForm
    tForm.Init Me, "select * from table1;", Me.cmdSaveAdd, Me.cmdSaveEdit, Me.cmdSaveClose, Me.cmdCloseNoSave
End Sub

 

[Edgar_]

@Pat Hartman
If you don't use the suitable events, properties and states for each feature, you're going to have a poor development experience. If a bound form solves your problems neatly, use them. If the flexibility of an unbound form does not meet your particular expectations, it's not mandatory to use it, but you have the right to know that the two possibilities exist in the context of Access.

It's up to you to test them and make an informed decision about which one is better for you. I recommend the two, as you can see in the first reply to this thread.

 

[MajP]

It's up to you to test them and make an informed decision about which one is better for you. I recommend the two, as you can see in the first reply to this thread

Sure, but I am pretty sure if the OP is here asking for help to build a simple cancel/save, there is no way they are capable of building even a simple unbound form. The amount of code for load, edit, add, delete, and save would be orders of magnitude more code and more complex code that a simple undo and dirty = false. There are times and places for unbound forms but probably not when the OP states

I am a beginner

I could just give them my transaction class module and that would be way easier than to implement an unbound form. It only requires a single line of code to instantiate. However, they would be absolutely clueless of what is going on.

 

[Edgar_]

As stated, you have the right to know there are two main ways to program your form and it's up to you to test how you feel more comfortable developing an app.

Beginners here are being taught about bang notation, event driven programming, they're using COM and byproducts of OOP and you're expressing sensitivity about a simple unbound form? Let's be serious.

 

[Gasman]

@Gasman,
Better yet, I will provide the Class to show you can turn any form into a transactional form.
1. Import class into VBE using the File Import.

2. On any form add the following buttons

Save Add
Save Edit
Save Close
Close (No Save)

3. Code on form
Do not give the form a Recordsource, but pass it in instead. Pass in the buttons.

Dim tForm As clsTransactedForm

Private Sub Form_Close()
    Set tForm = Nothing
End Sub

Private Sub Form_Open(Cancel As Integer)
    Set tForm = New clsTransactedForm
    tForm.Init Me, "select * from table1;", Me.cmdSaveAdd, Me.cmdSaveEdit, Me.cmdSaveClose, Me.cmdCloseNoSave
End Sub

Thank You @MajP

 

[jdraw]

Hey folks. An interesting discussion with lots of good advice and some sample databases. Hopefully the OP will return and take advantage of it.

 

[Pat Hartman]

As stated, you have the right to know there are two main ways to program your form and it's up to you to test how you feel more comfortable developing an app.

And as you can see the OP has disappeared.