DoCmd.Close (Bug or Feature?) 
Author Message
 DoCmd.Close (Bug or Feature?)

The setup:

1. Create New Database
2. Create New Table
3. Create a field in the table named "TableID", (defaults are Okay)
4. Define TableID field as primary key, or unique index
5. Save the table
6. Create a form (autoform works) based on the table
7. Place a button on the form that will close the form (use wizard), or 8.
DoCmd.Close - in the click event for the command button

The problem:

1. Open the form
2. Enter "SomeValue" in the text box
3. Move to the new record
4. Enter "SomeValue" in the text box
5. Attempt to close the form using the close (x) box
6. Observe correct behavior
7. Click "No" on dialog box asking if you still want to close form
8. Click on the command button
9. The form closed with no indication that there was a duplicate index, and
no indication that it just discarded all of your changes

You can click on the close button, File/Close menu, or control box until you
are blue in the face, you will not close the form without seeing the dialog.
The documentation for the Close action states that using the action is just
like using the close button, File/Close menu, or control menu.

This form only had a single field, but what if it had 20 fields and what if
the unique index was a composite with fields like (PatientNumber and
ProcedureDate), and what if I made a mistake and entered the wrong date and
the patient already had a procedure on that date.  When I close the form
there is no indication that the database did not add a record to the table.

Does anybody care?



Sun, 29 Jul 2001 03:00:00 GMT  
 DoCmd.Close (Bug or Feature?)
Jim,

Looks like it's a known bug. Check out this
http://x6.dejanews.com/getdoc.xp?AN=420835019. HTH

Dimitri

Quote:

> The setup:

> 1. Create New Database
> 2. Create New Table
> 3. Create a field in the table named "TableID", (defaults are Okay)
> 4. Define TableID field as primary key, or unique index
> 5. Save the table
> 6. Create a form (autoform works) based on the table
> 7. Place a button on the form that will close the form (use wizard), or 8.
> DoCmd.Close - in the click event for the command button

> The problem:

> 1. Open the form
> 2. Enter "SomeValue" in the text box
> 3. Move to the new record
> 4. Enter "SomeValue" in the text box
> 5. Attempt to close the form using the close (x) box
> 6. Observe correct behavior
> 7. Click "No" on dialog box asking if you still want to close form
> 8. Click on the command button
> 9. The form closed with no indication that there was a duplicate index, and
> no indication that it just discarded all of your changes

> You can click on the close button, File/Close menu, or control box until you
> are blue in the face, you will not close the form without seeing the dialog.
> The documentation for the Close action states that using the action is just
> like using the close button, File/Close menu, or control menu.

> This form only had a single field, but what if it had 20 fields and what if
> the unique index was a composite with fields like (PatientNumber and
> ProcedureDate), and what if I made a mistake and entered the wrong date and
> the patient already had a procedure on that date.  When I close the form
> there is no indication that the database did not add a record to the table.

> Does anybody care?



Sun, 29 Jul 2001 03:00:00 GMT  
 DoCmd.Close (Bug or Feature?)
Steve,

Actually, the documented issue with the close action/method is only part of
the problem.  The message that Dimitri referenced describes the rest of the
{*filter*}details.  The powers that be should be aware of the problem (I reported
it twice via tech support over a year ago, and something tells me that I'm
not the only one to complain about it <g>), but there's nothing about it on
the KB aside from the article to which you referred.

Nicole


Quote:
> Jim,

> It's a bug. See MS KB article Q131813, "ACC: Edits Not Processed w/ Close
> Action on Form (2.0, 7.0, 97)" (7/21/97).

> There are workarounds, but they're {*filter*}:

> - Add a line of code to save current record before closing form, as
> explained in the KB article metioned above. This means you have to trap
the
> error if record can't be saved, then display your own message asking user
> what they want to do. Basically, create a custom replacement function for
> DoCmd.Close.

> - Validate your data in the cmdClose_Click procedure.

> - Good old SendKeys! Use SendKeys "^{F4}" (CTRL-F4) to close regular
windows
> and SendKeys "%{F4}" (ALT-F4) to close pop-up windows. This will cause
> Access to handle the error messages for you, just like if you clicked the
> "x", File > Close, etc. Just don't send ALT-F4 from a non-pop-up window or
> you'll close Access!

> A co-worker is checking this in Access 2000. Will keep you posted...



Mon, 30 Jul 2001 03:00:00 GMT  
 DoCmd.Close (Bug or Feature?)
Nicole,

Thanks. I posted this issue on the Access 2000 beta NG, with a link to your
Dec. 98 message with all the details.

--
Steve
FMS, Inc.
Check out our newsgroups at news.fmsinc.com!

Quote:

>Steve,

>Actually, the documented issue with the close action/method is only part of
>the problem.  The message that Dimitri referenced describes the rest of the
>gory details.  The powers that be should be aware of the problem (I
reported
>it twice via tech support over a year ago, and something tells me that I'm
>not the only one to complain about it <g>), but there's nothing about it on
>the KB aside from the article to which you referred.

>Nicole



Mon, 30 Jul 2001 03:00:00 GMT  
 DoCmd.Close (Bug or Feature?)
Steve,

I was working on a new demo of the problem yesterday and discovered that the
behaviour encountered when cancelling the form's Unload event seems to have
changed, probably in SR-2.  I'm pretty sure that cancelling Unload used to
have no effect after error 2169 had been raised (i.e.: the form would still
close), but I really don't have time just now to reinstall Office just to
verify this.  At any rate, cancelling Unload under SR-2 does result in the
form remaining open even if error 2169 has been raised.  Unfortunately, the
new/changed data is still lost if the error 2169 "Yes" path is followed.  I
had thought that this might present an interesting opportunity to store the
data to an array or collection from the BeforeUpdate event, then repopulate
the form with the data after handling error 2169, but I haven't yet been
able to find an event that fires reliably after the data loss (not that I've
had much time to look into this, but the most obvious candidate would be the
form's Current event, and it doesn't fire after the data loss).  If there is
no event that can be used for this, I suppose one could use a timer hack and
test for the value of a flag set when error 2169 is handled, but that's
building one rather kludgy layer on top of another...

Nicole


Quote:
> Nicole,

> Thanks. I posted this issue on the Access 2000 beta NG, with a link to
your
> Dec. 98 message with all the details.



Tue, 31 Jul 2001 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Docmd.applyfilter bug in Access 2000 SR1

2. DoCmd.GotoPage Bug

3. Silent failure bug with DoCmd.OpenFormWhere?

4. Canceling DoCmd.Close

5. DoCmd.Close question

6. docmd.close problem

7. Debugging Close Database (DoCmd.Quit)

8. ACCESS 95/97 BUG/FEATURE, CAN YOU HELP ?

9. Word MailMerge - a bug or a feature

10. bug or feature with expression columns

11. CType(), Bug or Feature??

12. Bug or Feature?

 

 
Powered by phpBB® Forum Software