committing/rolling back all changes on form 
Author Message
 committing/rolling back all changes on form

In Access, how do I determine if all the changes that have been made to
a form are committed or rolled back?

The application I am working has a requirement that the user be able to
save the changes (Access' default behavior) or cancel the changes (the
challenging part).

My first thought was to place a call to DbEngine.BeginTrans in the open
or load event procedure and a call to DbEngine.Commit or
DbEngine.Rollback in the unload or close event procedure.  This,
however, does not work because access implicitly commits when moving off
a record.  At this point I should mention that the main form (which will
probably only be used to view a single record at a time) has several
subforms.

Of course there is the before update event procedure that can be
canceled, but that has the problem of only applying to one form (the
main form or one of the subforms).

Thanks,
Matt



Mon, 14 Jan 2002 03:00:00 GMT  
 committing/rolling back all changes on form
Matt,

Cannot be done in Access 97, you have no access to the Jet session where the
transaction would have to be placed. You would have to use unbound controls
and handle all updates yourself.

--
MichKa

-------------------------------------
don't send questions by e-mail unless
you're paying for it. (TANSTAAFL!) :-)

random junk of dubious value is at:
http://www.trigeminal.com


Quote:
> In Access, how do I determine if all the changes that have been made to
> a form are committed or rolled back?

> The application I am working has a requirement that the user be able to
> save the changes (Access' default behavior) or cancel the changes (the
> challenging part).

> My first thought was to place a call to DbEngine.BeginTrans in the open
> or load event procedure and a call to DbEngine.Commit or
> DbEngine.Rollback in the unload or close event procedure.  This,
> however, does not work because access implicitly commits when moving off
> a record.  At this point I should mention that the main form (which will
> probably only be used to view a single record at a time) has several
> subforms.

> Of course there is the before update event procedure that can be
> canceled, but that has the problem of only applying to one form (the
> main form or one of the subforms).

> Thanks,
> Matt



Mon, 14 Jan 2002 03:00:00 GMT  
 committing/rolling back all changes on form
I believe you'll have to use temporary tables.  Microsoft should have a
sample database for you to download at their site.  The sample is for order
entry where you have an Form based on the order table and a Subform based on
the order detail lines.  When you open an existing order, the original
information is written to two temporary tables:  one for the order and the
other for the detail lines.  That way, if you can restore the original order
when you click the cancel button on the Order form.  Perhaps you can use
this technique for your application.
Quote:

>In Access, how do I determine if all the changes that have been made to
>a form are committed or rolled back?

>The application I am working has a requirement that the user be able to
>save the changes (Access' default behavior) or cancel the changes (the
>challenging part).

>My first thought was to place a call to DbEngine.BeginTrans in the open
>or load event procedure and a call to DbEngine.Commit or
>DbEngine.Rollback in the unload or close event procedure.  This,
>however, does not work because access implicitly commits when moving off
>a record.  At this point I should mention that the main form (which will
>probably only be used to view a single record at a time) has several
>subforms.

>Of course there is the before update event procedure that can be
>canceled, but that has the problem of only applying to one form (the
>main form or one of the subforms).

>Thanks,
>Matt



Mon, 14 Jan 2002 03:00:00 GMT  
 committing/rolling back all changes on form
Why is there a Requirement to be able to Cancel changes?
Why not use the product as designed and save yourself a major headache?
Train users what "saving" a record means.
Also, show them where the ESC key is.

If you HAVE to have the ability to Cancel changes then the Cancel event
works fine.
Just don't use ANY subforms. Make each form a Main form.
--
HTH
Joe
Check out Dev Ashish's web site for answers to common questions
http://home.att.net/~dashish/


Quote:
> In Access, how do I determine if all the changes that have been made to
> a form are committed or rolled back?

> The application I am working has a requirement that the user be able to
> save the changes (Access' default behavior) or cancel the changes (the
> challenging part).

> My first thought was to place a call to DbEngine.BeginTrans in the open
> or load event procedure and a call to DbEngine.Commit or
> DbEngine.Rollback in the unload or close event procedure.  This,
> however, does not work because access implicitly commits when moving off
> a record.  At this point I should mention that the main form (which will
> probably only be used to view a single record at a time) has several
> subforms.

> Of course there is the before update event procedure that can be
> canceled, but that has the problem of only applying to one form (the
> main form or one of the subforms).

> Thanks,
> Matt



Mon, 14 Jan 2002 03:00:00 GMT  
 committing/rolling back all changes on form
... because people want to use Access, but they don't want to use Access
<sigh> .


Quote:
> Why is there a Requirement to be able to Cancel changes?
> Why not use the product as designed and save yourself a major headache?
> Train users what "saving" a record means.
> Also, show them where the ESC key is.

> If you HAVE to have the ability to Cancel changes then the Cancel event
> works fine.
> Just don't use ANY subforms. Make each form a Main form.
> --
> HTH
> Joe
> Check out Dev Ashish's web site for answers to common questions
> http://home.att.net/~dashish/



> > In Access, how do I determine if all the changes that have been made to
> > a form are committed or rolled back?

> > The application I am working has a requirement that the user be able to
> > save the changes (Access' default behavior) or cancel the changes (the
> > challenging part).

> > My first thought was to place a call to DbEngine.BeginTrans in the open
> > or load event procedure and a call to DbEngine.Commit or
> > DbEngine.Rollback in the unload or close event procedure.  This,
> > however, does not work because access implicitly commits when moving off
> > a record.  At this point I should mention that the main form (which will
> > probably only be used to view a single record at a time) has several
> > subforms.

> > Of course there is the before update event procedure that can be
> > canceled, but that has the problem of only applying to one form (the
> > main form or one of the subforms).

> > Thanks,
> > Matt



Wed, 16 Jan 2002 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Rolling back RDC changes

2. Rolling Averages - back to the drawing board

3. Roll back transaction Error handling

4. Rolling back to vbx's afer upgrading to ocx's

5. RDO Problem when rolling back transaction - Function sequence error

6. "rolling back" on AddNew

7. Implicit roll back when using server side cursor

8. Rolling back transactions

9. COM+ question: SetAbort not rolling back transaction?

10. MTS, VB and rolling back transactions

11. SetAbort does not roll back transaction

12. GetTickCount Rolls Back To Zero?

 

 
Powered by phpBB® Forum Software