Order of operations for canceled edit. (1 Viewer)

[PhoenixofMT]

Which events trigger when an edit is canceled?
I have some SQL that adds a record to a junction table when it is not in the list. If the user cancels the edit (i.e. hits escape part way through the form) I want to remove the record from the junction table.

Thanks

 

[CyberLynx]

You know....I'm not sure there is such an event for this sort of thing.

What you could do however is either confirm that the Data was stored or disallow the use of the Escape key during the operation or both.


To prevent the Escape key from being used in Form add his code to the Forms' OnKeyDown event:

If KeyCode = 27 Then   [COLOR="DarkGreen"]'KeyCode for the ESCAPE Key.[/COLOR]
   KeyCode = 0
   MsgBox "You can not use the Escape Key at this moment.", _
          vbExclamation, "Writing To Table..."
End If

Just before the Query operation commences have:

Me.KeyPreview = True


and when the query operation is finished:

Me.KeyPreview = False


.

 

[PhoenixofMT]

Hmm... that may work, indirectly.... How many ways are there to cancel a record edit. If the Esc key is the only way, I could just use that as my event.

Or maybe I could set up a delete query, to search for entries in the junction table that are not in the data table, that runs when the form closes.

 

[LPurvis]

Are you sure you want to work it that way?
Wouldn't it be safer to prevent an Undo on the form?
Or to only create the link record when the main record is committed (AfterInsert).

Creating records on the fly based on bound UI interaction is always going have the capacity to leave you chaging your tail otherwise.

There's the Undo event in your forms (since Acc2002 as I recall) which you can use to monitor (or prevent) such form record actions anyway.

 

[PhoenixofMT]

I'm stuck using Access 2000, so I don't have an Undo event.

The problem I foresee with preventing an undo is the user who will (inevitably) discover that they made a mistake in the field in spite of the ""Value" does not exist, would you like to add it?" pop-up. If they are forced to complete the record I now have two records that will have to be removed.

I think the problem is rooted in using the NotInList event to add to the junction table. I think I'll look at adding that record in the AfterUpdate (?) event.

 

[LPurvis]

I'm afraid I can't respond with any real opinion on your question.
There's not enough information about what you're doing - or by what decision making process it is implemented.
If you're basing everything from a listbox then Afterupdate yeah sure.
On the form itself - AfterInsert detects new record commital.

 

[PhoenixofMT]

Sorry, I tend to run on most of the time. I guess I held back too much.

I am trying, with this database, to mirror and hopefully replace a documented (i.e. paper and scanners) process. I have a table that keeps track of programs (tblSoftwareControlLog) and a table that keeps track of changes to said programs (tblChangedToTestPrograms). They are in a Few:Many relationship (respectively). There is uncertainty about whether the program name will be able to stay unique in the control log (thanks to 8.3 file names), so I have another table (tblPrograms)with just the program names to join everything up properly and be a reference for some other things.

I've been using the NotInList event to add new records to tblPrograms because that solution worked in another place I needed to add records to junction tables.

I think the way to go with this is to add the record to tblPrograms with the AfterInsert event, as you said, with some code to make it fizzle quietly when trying to make duplicate records.