is there a way to save and Don't save bounded fields? (1 Viewer)

rehanemis

Registered User.
Local time
Today, 23:04
Joined
Apr 7, 2014
Messages
189
Hi,
I am playing with ms access forms. So I created a form using Form Wizard and my form fields are bounded. So I have two buttons 1- Save 2- Cancel.
I want to save the record to table is Save button is presses and don't save the record (either user entered data into the fields) if Cancel button is pressed.

any suggestion?
 

arnelgp

..forever waiting... waiting for jellybean!
Local time
Tomorrow, 03:04
Joined
May 7, 2009
Messages
16,810
use Transactions to save/cancel your updates.
or you can use the Form's BeforeUpdate event to save/ cancel your updates.
 
Last edited:

arnelgp

..forever waiting... waiting for jellybean!
Local time
Tomorrow, 03:04
Joined
May 7, 2009
Messages
16,810
this is a demo.
open "1000 Sales Records" form.
1. delete some "text", go to another record and delete more text.
press Cancel button.
2. delete some Records.
press cancel button.
 

Attachments

  • UsingTransaction.accdb
    696 KB · Views: 93

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 14:04
Joined
Feb 28, 2001
Messages
23,151
If you have a "Don't Save" case and you wish to merely discard everything without saving anything, make your Don't Save button using the form's Button Wizard. One of the operations will UNDO the changes. That is the simplest way when ALL of the fields are bound. The Save button is also available from the form's Button Wizard. In this context, for a fully bound form,

The Save operation makes the underlying record's fields match the controls to which they were bound. I.e. the current record is made to match the form. Since this counts as making the record 'current' you will get a Form_Current event when the save is complete.

The Undo operation makes the underlying record's fields reload the controls to which they were bound, overwriting the changes in the controls. OK, for the purists, technically this makes all bound control .Value properties match the same control's .OldValue properties, which were loaded during the previous Form_Current event. That is, the form is made to match the current record. Since this is an Undo action, it triggers the Form_Undo event when complete.

You said this was a case of all controls being bound. IF you had any unbound controls, they don't have .OldValue properties so they don't get reset by a Form_Undo operation.
 

rehanemis

Registered User.
Local time
Today, 23:04
Joined
Apr 7, 2014
Messages
189
Thanks for all replies. I will play with techniques after few hours.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 15:04
Joined
Feb 19, 2002
Messages
36,871
The code for the cancel button:

Me.Undo

The code for the save button:

DoCmd.RunCommand acCmdSaveRecord

PS, the Transaction code needs work. It only works correctly if you use the buttons. Here is a picture of what happens. I changed the Asia region name to add xxxx at the end. The pencil went away when I moved to a new record so Access is telling me that the record has been changed AND COMITTED. If I close the form, the change is silently discarded but the user thinks the change has been saved.
zzError.JPG
 

arnelgp

..forever waiting... waiting for jellybean!
Local time
Tomorrow, 03:04
Joined
May 7, 2009
Messages
16,810
If I close the form, the change is silently discarded but the user thinks the change has been saved.
I want to save the record to table is Save button is presses
the default action, as per request is not to save.

are you my "dark" shadow? everywhere i post, you Contradict it!
 
Last edited:

KitaYama

Active member
Local time
Tomorrow, 04:04
Joined
Jan 6, 2022
Messages
537
this is a demo.
open "1000 Sales Records" form.
1. delete some "text", go to another record and delete more text.
press Cancel button.
2. delete some Records.
press cancel button.
@arnelgp
Thanks for the sample file. I'd always wondered how a transaction works behind a bound form.
Do you happen to have a sample file without using a class?
Thanks.
 

arnelgp

..forever waiting... waiting for jellybean!
Local time
Tomorrow, 03:04
Joined
May 7, 2009
Messages
16,810
. I'd always wondered how a transaction works behind a bound form.
Transaction works by Caching all the Updates (insert, update, delete) of all records of the
form in memory. meaning it does not physically saved the record in the disk yet until you
tell it to (commit).

without using Class.
 

Attachments

  • UsingTransactionNoClass.accdb
    1.2 MB · Views: 82

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 20:04
Joined
Sep 12, 2006
Messages
14,901
Thanks for all replies. I will play with techniques after few hours.
The standard behaviour of access is to try to save changes automatically. Personally, I think trying to prevent that standard behaviour is very difficult to do. Experienced users won't expect to explicitly click "save". It's rather like removing the standard buttons at the top tight of a form. Something to be used sparingly if at all.

Perhaps @arnelgp can confirm, but I imagine the liberal use of transactions may cause complications in a multi user environment. If your change isn't committed, what happens to subsequent users who need your data. Do they have to wait for your transaction to complete?
 

MajP

You've got your good things, and you've got mine.
Local time
Today, 15:04
Joined
May 21, 2018
Messages
6,437
The standard behaviour of access is to try to save changes automatically. Personally, I think trying to prevent that standard behaviour is very difficult to do. Experienced users won't expect to explicitly click "save".
Yeah, a "Save Button" in access is like going outside in the middle of winter and wanting an extra feature to help you get cold. In Access the mindset needs to change from "save / cancel" to "confirm / cancel".
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 14:04
Joined
Feb 28, 2001
Messages
23,151
Just for the record, in my biggest project for the Navy, the ideas of a SAVE and a CANCEL button were necessary due to the Access behavior of automatically saving on navigation. Because this was a security-related record-keeping database, we had to include certain affirmations that would have been lost by allowing automatic saves on a navigation. Admittedly an extreme requirement but what do you do when the IT department AND the boss both want it? AND can cite regulations for it.
 

MajP

You've got your good things, and you've got mine.
Local time
Today, 15:04
Joined
May 21, 2018
Messages
6,437
Because this was a security-related record-keeping database,
Using Access????
 

KitaYama

Active member
Local time
Tomorrow, 04:04
Joined
Jan 6, 2022
Messages
537
@MajP I think it depends on the situation.
Just curious to know how you save a record on a single form and on edit mode? You move next and then move previous or you use a Save button?
 

MajP

You've got your good things, and you've got mine.
Local time
Today, 15:04
Joined
May 21, 2018
Messages
6,437
I think it depends on the situation.
No, it does not. It just saves.
Or to say it another way. I probably have built easily over 1k Access databases and never added a save button. It is a "football bat".
 

MajP

You've got your good things, and you've got mine.
Local time
Today, 15:04
Joined
May 21, 2018
Messages
6,437
Just curious to know how you save a record on a single form and on edit mode
Ehhh, do just about anything like close the form, move to the next record, I don't know.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 15:04
Joined
Feb 19, 2002
Messages
36,871
the default action, as per request is not to save.
As the others have said. The standard behavior of Access is to save. In fact, Access takes saving records as a personal mission and it saves under numerous situations. In fact, the usual complaint is how do I stop it from saving rather than how do I make Access save. But the question is only asked by people who don't understand the form's BeforeUpdate event. Plus as I showed with the picture, the change appears to have been saved since the pencil disappeared.

The code you have posted is dangerous and others should know. Rather than complaining and accusing me of attacking you personally, just say "thank you, I didn't notice that. I'll fix it".

@KitaYama FYI, Access wraps your Form inside a transaction already so this code is wrapping the transaction inside a transaction. Sure, it's cool. It's a class module which no one understands. But to what end? It appears from his response, arnelgp's "end" is to stop Access from automatically saving. However, Access gives you complete control over whether or not the form's record gets saved. All you have to do is to understand the form level events. Those are what Access uses to control the transaction it has already started. To cancel a save, just use the Form's BeforeUpdate event. You don't need a class module to do this. You are already in one.

There are valid reasons for using transactions. A single record update form isn't one of them. Transactions are used when you need to make multiple updates and you need all of them to be committed or all to be rolled back. The most frequent example is double entry book keeping. You need to add both the credit and the debit entries inside a transaction because if one is committed and the other isn't, the books will be out of balance. It is also used for certain batch updates. For example, in a credit card processing center, a check is received and it needs to be split to apply to multiple accounts. Again, all the separate transactions need to be applied or they need to be rolled back. I used to use transactions quite frequently back in the olden days when I was working with COBOL and doing lots of batch processing. We would need to process an entire file of input records. Since the files were so large, we would take checkpoints within the transaction so that if something happened, we didn't need to go back to the beginning of the file, we could resume at the last valid checkpoint. Not much batch processing gets done with Access but I've actually done some. One of my clients offered home healthcare services to private pay clients as well as those on Medicaid and other government programs. Most services were paid for by the state and so each month we would have to send (invoices) and receive (payment confirmations) files that could go to a million records since each visit for each client generated a transaction and the transactions which were EDI (Electronic Data Interchange) could be multiple records each. Transactions came to the rescue. checkpoint after every 20,000 transactions (which could be 100,000 records) so if something happened we wouldn't have to reprocess the entire file.
 
Last edited:

Pat Hartman

Super Moderator
Staff member
Local time
Today, 15:04
Joined
Feb 19, 2002
Messages
36,871
For those who have never heard of EDI, it refers to a bunch of different types of transactions that are used by companies to exchange information with other businesses. They are always B2B. Individuals are not involved. The EDI formats are industry standards so when your doctor's office sends its bills every month, they probably send them to a clearing house and the clearing house breaks apart the billing file and combines it with the bills from other doctors and sends files to every insurance company. In the case of my client, we were always paid by the state because they administered Medicaid and the other federal programs.

Other common transactions used by business are:
Request for Quotation
Response to Request for Quotation
Price/Sales Catalog
Ship Notice/Manifest
Invoice
 

Users who are viewing this thread

Top Bottom