Discarding updates (1 Viewer)

ryetee

Registered User.
Local time
Today, 22:55
Joined
Jul 30, 2013
Messages
952
I have a continuous form so am effectively displaying all records on one form.
The user wants to the ability to cancel all the changes on leaving the form. I can't see how to do this only drop the very last change.
Is it possible?
 

Mark_

Longboard on the internet
Local time
Today, 14:55
Joined
Sep 12, 2017
Messages
2,111
The user wants to the ability to cancel all the changes on leaving the form.

Each instance of a form is unique. I am guessing your user would like to enter a set or records but be able to roll back all changes?

What back end are you using?
 

Galaxiom

Super Moderator
Staff member
Local time
Tomorrow, 07:55
Joined
Jan 20, 2009
Messages
12,852
It can be done using a Transacted Bound Form.
There is an example on this thread.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 17:55
Joined
Feb 19, 2002
Messages
43,302
If the records belong to a set and you want to insert the entire set or nothing, there are a couple of options. I wouldn't even consider using an unbound form to solve this problem. I would either use shadow tables where the set is worked on and when it is complete, code validates it and then takes the data from the temp table and appends it to the permanent table followed by deleting it from the temp table. This append/delete action should always be done inside a transaction to ensure that it is all or nothing.

A simpler solution that does not require extra tables is to include a complete flag on the parent record. This is easiest to implement if you do it from the start because all queries that use this data (except the maintenance form) will need to ignore incomplete sets of data. You will also need a query to find abandoned data and prompt the user to finish it. This problem also arises in the temp table scenario.

The unbound form solution is difficult ti implement for sets of records. It is also inflexible in that unless you also use a temp table (if you do there is no need for an unbound form) then the user can't stop in the middle of processing a batch. He either needs to complete the entry or abandon it and start from scratch at another time.
 

arnelgp

..forever waiting... waiting for jellybean!
Local time
Tomorrow, 05:55
Joined
May 7, 2009
Messages
19,245
here is Mr.Galaxiom's sample with buttons to Save All or Discard All.
 

Attachments

  • TransactedBoundForm.zip
    20.6 KB · Views: 51

ryetee

Registered User.
Local time
Today, 22:55
Joined
Jul 30, 2013
Messages
952
Each instance of a form is unique. I am guessing your user would like to enter a set or records but be able to roll back all changes?

What back end are you using?

Enter, update, delete etc etc for a set of records yes

It's all Access 2016. Tables are in a back end DB
 

ryetee

Registered User.
Local time
Today, 22:55
Joined
Jul 30, 2013
Messages
952
Thanks to arnelgp, Pat Hartman and Galaxiom - I will read up and get back to you all!
 

ryetee

Registered User.
Local time
Today, 22:55
Joined
Jul 30, 2013
Messages
952
It can be done using a Transacted Bound Form.
There is an example on this thread.


OK I've now incorporated this into a new form with a proper table(!)
and I'm having problems.
It's all down to the use of a split form and making changes to the datasheet part of it.
If I do this then the boolean used boolFrmSaved seems to get set back to false.
If I make the changes on the non datasheet bit it works.
Also any changes on the datasheet view are all discarded!

Any idea what I need to change to make this work?
 
Last edited:

Mark_

Longboard on the internet
Local time
Today, 14:55
Joined
Sep 12, 2017
Messages
2,111
Go back to what you were originally doing?

I have a continuous form

You can set up a continuous form to look like a data sheet, and it has the advantage of allowing finer control over data entry.
 

ryetee

Registered User.
Local time
Today, 22:55
Joined
Jul 30, 2013
Messages
952
Go back to what you were originally doing?



You can set up a continuous form to look like a data sheet, and it has the advantage of allowing finer control over data entry.

I actually started to do this as a continuous form but got bogged down sizing the controls and getting it to look good so changed it to a split form because

a) I want to apply this to the other forms which are all split. They're not that many so I could easily change.
b) more importantly the user will want to use the column filter options and also want the ability to size each column including hidng and un hiding.

Incidentally if I use the continuous option (which works) but then select datasheet view then this works so it must be a split form problem.
 
Last edited:

Minty

AWF VIP
Local time
Today, 22:55
Joined
Jul 26, 2013
Messages
10,371
Have a search on here for split forms and issues, there are plenty.

They don't behave much like a real form in many ways , and have led to all sorts of kludges and work arounds. I would think unless you have a lot of time to waste you may want to investigate a "better" solution.

There is a long thread about an 'Emulated Split form" that some pretty clever people struggled to get to work efficiently. Thread here https://access-programmers.co.uk/forums/showthread.php?t=294421
 

ryetee

Registered User.
Local time
Today, 22:55
Joined
Jul 30, 2013
Messages
952
I think I'll go down the continuous form route!!
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 17:55
Joined
Feb 19, 2002
Messages
43,302
Do you have a solution because "using continuous forms" doesn't sound like it solves your problem. When you have a set of data, the implication is there is a second table involved that controls the set. For example, you might have a batch of payments that all have to be applied or not applied. Because the way bound forms work, this is not directly possible since each record is committed separately from every other record and due to the possibility of user error or system failure, not all records might be entered before the form is closed so you have do do something else. Galaxiom suggested a transaction. That's the right concept but forms already operate within a transaction so the example doesn't do anything that Access isn't already doing and the example uses a continuous form. A continuous form is just like a single form in that it updates ONE record at a time. So, if you are interested in having more detail on the two suggestions I offered, just post back on the one you think might work best for you and I'll go into more detail.
 

ryetee

Registered User.
Local time
Today, 22:55
Joined
Jul 30, 2013
Messages
952
Do you have a solution because "using continuous forms" doesn't sound like it solves your problem. When you have a set of data, the implication is there is a second table involved that controls the set. For example, you might have a batch of payments that all have to be applied or not applied. Because the way bound forms work, this is not directly possible since each record is committed separately from every other record and due to the possibility of user error or system failure, not all records might be entered before the form is closed so you have do do something else. Galaxiom suggested a transaction. That's the right concept but forms already operate within a transaction so the example doesn't do anything that Access isn't already doing and the example uses a continuous form. A continuous form is just like a single form in that it updates ONE record at a time. So, if you are interested in having more detail on the two suggestions I offered, just post back on the one you think might work best for you and I'll go into more detail.

I used Galaxiom's example and it works well on a single table and for what I need at the moment.
My user wants the ability to back everything out so I'm sure I'll hit something more complicated later on so will be back then!
 

Users who are viewing this thread

Top Bottom