That seems to be a fair assessment of the problem to me, Boris.

My impression is that use of the form's Recordset property is quite rare. It
was a new feature in Access 2000, and my impression is that most developers
continued manipulating the RecordSource property as they were accustomed to
doing in earlier versions. That's what I do. To test whether a form is
unbound, I would test the length of the RecordSource property ...

If Len(Me.RecordSource) 0 Then

--
Brendan Reynolds (MVP)
http://brenreyn.blogspot.com

The spammers and script-kiddies have succeeded in making it impossible for
me to use a real e-mail address in public newsgroups. E-mail replies to
this post will be deleted without being read. Any e-mail claiming to be
from brenreyn at indigo dot ie that is not digitally signed by me with a
GlobalSign digital certificate is a forgery and should be deleted without
being read. Follow-up questions should in general be posted to the
newsgroup, but if you have a good reason to send me e-mail, you'll find
a useable e-mail address at the URL above.


"Boris" wrote in message
...
I changed now the VBA code to use DAO (deleting the record with
"Me.Recordset.Delete") but that doesn't help. The runtime error persists
no
matter how you delete the record.

Conclusion: If you use VBA to delete all records in a recordset that is
bound to a form RecordCount is updated but BOF and EOF are not! Calling
Requery doesn't help. When the form is then closed it tries to save the
records that don't exist any more - runtime error 3021.

Work-around: You have to force the bound form to reconsider the Recordset
after all records have been deleted (eg. by calling MoveFirst). This
updates
BOF and EOF, and the form will not try to save records any more when it is
closed.

Now is this a bug in Access? I understand that a form doesn't know when
records are added or deleted in VBA. However I thought calling Requery
makes
the form know?

Boris