Re: Aborting form entry

Thankyou. That really was a most gracious response. I am sorry that I have
not replied before but an overloaded lorry, or truck, as you may prefer to
call it, brought down my overhead telephone line six days ago and it has only
just been repaired. I have been more or less incommunicado during the
interval.

As a result of everyone's help, I think I now understand the ramifications
of form closure and data saving more clearly. As a result, any hope that I
had overlooked the 'magic button' has evaporated. To misquote a well-known
saying, it would appear that you can discard some data in all circumstances
and all data in some circumstances but what you can't do is discard all data
in all circumstances. I will therefore have to stick to the use of temporary
tables. Even though the procedure is rather involved, it is the nearest I am
likely to get to a 'one size fits all' solution.

As to the cow, I am afraid it had to go. It was eating all the flowers in
the garden and my wife demanded that I take it to market. However, on the
way, I met a man who offered to exchange it for a bag of magic beans. I
accepted. (Apart from anything else it saved me a long walk.) Do you think
that was wise?

--
Peter Hallett


"Albert D.Kallal" wrote:

> "Peter Hallett" <PeterHallett@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:11F7265E-0924-4F39-A13C-9711B4296D49@xxxxxxxxxxxxxxxx
> > not a little humbled to have a
> > dressing down from a real expert but before you get too irate could I
> > point
> > out, in my defence, that the situation is not quite as you portray it.
>
> Yikes...I hope my post was not viewed as a dressing down.
>
> > My
> > problem arose with ALL forms, not just continuous ones.
>
> Ah..then I stand corrected!!! I was very much under the impression that when
> you tried some of suggest (using the before update "cancel"), the reason why
> those answers were of no use to you because you failed to mention that you
> were using a continues form. (it looks like I am dead WRONG on this
> assumption!!!). My apologies to you!
>
> > It was not until I
> > tried the solutions I had been offered that it became clear that
> > continuous
> > forms were going to be the stumbling block.
>
> Ok...that really fair (nice) on your part to point out the above. Really,
> when reading your post, I had assumed that the advice given what ONLY no use
> to use since you had left out the fact of a continues form. Those examples
> posted should allow you to bail out on a record on a form with ease. The
> fact
> that those suggestions did not work for you really threw me off. (they
> should work). The fact that you are being gentleman, and come back and
> say..hey, you know what..those continues forms are really going to be a
> problem!!
> Your quest for a solution, and questions are good. Don't let some person who
> snapped at you (me) take anything away here.
>
> > I would like to have the power
> > of foresight but, unlike MVPs, I fear that it is something I lack.
>
> hey, that is ok. I think the fact that I spent time mention that
> transactions CAN in fact be used for forms does help.
>
> > The reasons that I am prepared to risk the wrath of the experts is that
> > (a)
> > I just want to solve my problems and write better Access code and (b)
> > since
> > you admit that the inabilitiy to quit forms and abandon changes is a
> > problem
> > with Access, there must be a lot of other non-experts, like me, who have
> > found themselves in similar difficulties.
>
> Yikes...wrath seems to hard!! I was just trying to point out that you got a
> whole truck load of answers....and none really were of use to you! (and, you
> point out that the issue was NOT *just* continues forms here!!).
>
> >
> > "I have a table on which I will carry out a series of operations which
> > will
> > change the data in that table. I then wish to have the option of either
> > retaining the amended data or restoring the table to its original state."
> > That is neither too prolix nor too vague, I hope. Now we don't have to
> > make
> > distinctions between continuous forms and other types.
>
> Ok, I going to have clear one thing on the above:
>
> If those "series of operations" is a bunch of code that updates reocrdssets,
> then
> a simple rollback, or commit will do the trick.
>
> However, if those series of operations is done by a user forms, then commit,
> and roll back will not work and is useless to you.
>
> So, if you got some code that processes data, and commit/rollback is a snap.
>
> >
> > Would you disagree with that restatement of the situation? I'll risk
> > another lecture if you would like to give me more of your advice.
>
> Hum, again, I feel bad that my post seemed like a lecture. And, I freely
> admit I did miss understand the reasons for you responding and telling
> people
> the solutions given were of no use.
>
> however, at the end of day, no problem here. I going to work a bit harder
> and try not to misunderstand posts like this.
>
> >the bigger the response, the
> >more information I get. I might even find a use for the rope, if I can get
> >the cow off it.
>
> Right on..that is funny! You know, I think I am going to STOP trying to use
> humor
> in my posts.....I don't think it comes off the right way!!
>
> So, as mentioned, if you forms do NOT have a sub-form and maintain a
> parent/child relationship, then binding your own reocdsets to code is VERY
> easy here.
>
> > is that, if the original table is
> >involved in a relationship, it cannot be deleted or replaced with the
> >buffer
> >table.
>
> Very good point.
>
> I will say that the binding of a form to a recordrset and using transactions
> *WILL* work even when the tables are involved with relations. (you just
> can't use the built in master/child links for a form when you do this).
>
> I going to post a continues form example ASAP that shows you how to
> bail out..and I guessing it should take less then 10 lines of code.
>
> --
> Albert D. Kallal (Access MVP)
> Edmonton, Alberta Canada
> pleaseNOOSpamKallal@xxxxxxx
> http://www.members.shaw.ca/AlbertKallal
>
>
>
>
.