none
Understanding "Wait For Post Processing" avd Me.Dirty = False RRS feed

  • Question

  • Using Access 2013

    Wait For Post Processing is by default set to No on every Form.
    I now try to understand what it does and at first it seems simple when pressing F1 and read the help:

    "Applies to: Access 2013 | Office 2013

    You can use the Wait For Post Processing property to specify that the form waits until processing of any operations (for example, running a macro) triggered by a user change to form data is complete before proceeding with the next operation"

    But on the same page its written:
    "Remarks

    This property is designed to work with Access 2010 web databases only. When this property is set to Yes, if a user changes data in a form that then triggers a data macro, the form will wait for the macro to finish before proceeding."

    Does Wait For Post Processing work with 2013 or not?

    I have had some problem with saving of data on SubForms. To force Access to save data I use Event procedure After Update "Me.Dirty = False".

    Is "Wait For Post Processing" - Yes and "Me.Dirty = False" a right combination or not?



    Best // Peter Forss Stockholm and Sigtuna GMT +1.00

    Wednesday, October 7, 2015 1:35 PM

Answers

  • In either case (2010, or 2013), the feature ONLY applies if you have a data macro, and have a published web 2010 format application.

    So yes, the feature works, but it ONLY applies to a 2010 web published application that 2013 supports.

    In your context? (context is ALWAYS everything!!!).

    No!

    Since you are talking about a client only (non web) application, then the setting has nothing to do with your issue.

    Unless of course this is a 2010 web application published with data macros – then yes the setting will apply in your case – includes 2013 that opened the 2010 web application.

    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Saturday, October 10, 2015 8:27 PM

All replies

  • In either case (2010, or 2013), the feature ONLY applies if you have a data macro, and have a published web 2010 format application.

    So yes, the feature works, but it ONLY applies to a 2010 web published application that 2013 supports.

    In your context? (context is ALWAYS everything!!!).

    No!

    Since you are talking about a client only (non web) application, then the setting has nothing to do with your issue.

    Unless of course this is a 2010 web application published with data macros – then yes the setting will apply in your case – includes 2013 that opened the 2010 web application.

    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Saturday, October 10, 2015 8:27 PM

  • I have had some problem with saving of data on SubForms. To force Access to save data I use Event procedure After Update "Me.Dirty = False".



    Best // Peter Forss Stockholm and Sigtuna GMT +1.00

    If you're using the Form.AfterUpdate event, then setting Me.Dirty=False is a waste of time and may cause undesired results. Once the AfterUpdate event fires, the record is already saved.
    Sunday, October 11, 2015 1:52 AM
  • I use AfterUpdate event on fields

    Private Sub OG_AfterUpdate()
    Me.Dirty = False
    End Sub

    May this cause undesired results?


    Best // Peter Forss Stockholm and Sigtuna GMT +1.00

    Sunday, October 11, 2015 5:04 AM
  • Personally, I don't like applications designed to automatically and silently save a record after a field is updated.  I would say "Yes," there are potentials for problems.  The record should only be saved at the user's request when they are ready and have completed the entire record and all required fields.  There are exceptions to this, but as a rule of thumb, I wouldn't commit a record without the user's knowledge and approval.
    Sunday, October 11, 2015 5:52 PM
  • I would say "Yes," there are potentials for problems.

    Hi RunningMan,

    Interesting! Can you give some examples of such potential problems?

    Imb.

    Sunday, October 11, 2015 7:42 PM
  • I would say "Yes," there are potentials for problems.

    Hi RunningMan,

    Interesting! Can you give some examples of such potential problems?

    Imb.

    Hi Imb,

    I would think that the entire context of my previous post should clue the reader in to potentials for problems. 

    Suppose the user is working in an environment where additions are allowed, but deletions or edits are not.  You save the record without the user being aware and you may have committed a record the user may otherwise have decided they wanted to abort or needed to correct.

    Suppose your user likes to skip around the data entry form adding data in different locations.  Then they go to your field that's going to save the record when updated, but they don't know that.  Now you have issues where the record is either committed and incomplete, or there are errors appearing for an unknown reason to the user because some required data element wasn't added.

    There are numerous other reasons I can think of that you should not save a record without the user being aware.  However, in short, it just isn't a good practice.

    Sunday, October 11, 2015 11:24 PM
  • I would think that the entire context of my previous post should clue the reader in to potentials for problems. 

    Suppose the user is working in an environment where additions are allowed, but deletions or edits are not.  You save the record without the user being aware and you may have committed a record the user may otherwise have decided they wanted to abort or needed to correct.

    Suppose your user likes to skip around the data entry form adding data in different locations.  Then they go to your field that's going to save the record when updated, but they don't know that.  Now you have issues where the record is either committed and incomplete, or there are errors appearing for an unknown reason to the user because some required data element wasn't added.

    There are numerous other reasons I can think of that you should not save a record without the user being aware.  However, in short, it just isn't a good practice.

    Hi RunningMan,

    Thank you for the answer. In general I think you are absolutely right.

    The reason form my question was to test different pro's and contra's to my approach. I developed a systematics in which I can assign to each control in a form property-like and method-like definitions, depending on the underlying field. The result of this is, that you can only exit a control if all necessary checks are passed. These checks can be key related, duplicates, syntax checks, value checks, etc.

    Based on this, new records are only saved on a record base after confirmation of the user, but in existing records the changes are saved on a control (field) base without confirmation. This means there is hardly any record locking during record editing. In those cases that in an existing record the user enters a wrong value in a control (thus meaning that the previous value was incorrect), the user can edit that value again.

    Until now all this works perfectly in my (80+) applications.

    Imb.


    Addition: edit via special (separate) forms always confirmation, to distinguish between accepting the value and just closing the form.
    • Edited by Imb-hb Tuesday, October 13, 2015 9:39 AM Addition
    Tuesday, October 13, 2015 8:38 AM