displaying a blank form

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Is there any way to display a blank form (no record showing) besides usin
DoCmd.GoToRecord , , acNewRe
I don't want a new record, I just want to go into a blank form and allow the user to click buttons I set up to Add, Edit, Delete and Save records. I get the buttons to work no problem (with the wizard) I just would like to include code so that after each of these processes finishes (and when first entering the form) the form is just a blank.
 
If you are using a bound form, then the NewRecord is your only choice. The
form has to be bound to some record. The NewRecord is a special virtual
record that Access provides for this purpose.

If you the form is unbound (which some people prefer as it gives them more
control over data validation) this is not a problem. You simply delete all
the values from the controls in the form and you have a blank form.
However, in this case you have to write code to save the data (and I don't
must mean the SAVE command, you have to write the value of each control to a
record in the database.), delete, undo, etc.

Overall, a bound form is easier.

--
--Roger Carlson
www.rogersaccesslibrary.com
Reply to: Roger dot Carlson at Spectrum-Health dot Org

Macy said:
Is there any way to display a blank form (no record showing) besides using
DoCmd.GoToRecord , , acNewRec
I don't want a new record, I just want to go into a blank form and allow
the user to click buttons I set up to Add, Edit, Delete and Save records. I
get the buttons to work no problem (with the wizard) I just would like to
include code so that after each of these processes finishes (and when first
entering the form) the form is just a blank.
 
(snip)
If you the form is unbound (which some people prefer as it gives them more
control over data validation) ...


Just for my interest, what would you see as being a data validation
requirement that is easier to do or control in an unbound form,
compared to a bound form?

TC
 
The main problem with bound forms is that it will save data 1) when you move
to another record, 2) when you close the form, 3) when you explicitly save,
4) when you move to a subform.

The last is the most obvious example. If you have a main form with several
subforms, when you move to a subform the main record is saved. But suppose
at least 1 value MUST be chosen in the subform and further that you don't
realize that you don't have a value to select, after you have entered the
subform. By rights, this record (the main one) should not be saved, but it
has. You cannot Undo the record, you must Delete it. This can be further
complicated if you have multiple subforms of this type. You may need to
delete records from multiple tables.

Even without subforms, if you have very complex data validation, it can be a
mess to deal with BeforeUpdate, AfterUpdate, NewData, OldData, etc.
Especially if the validation involves the value of another field.

In an unbound form, nothing gets saved to the table until it is done so
explicitly. Therefore you have much greater control of the validation
process.

Now I'm not saying that developing an unbound form is easier. Far from it.
But if you really want complete control of the validation process, an
unbound form is the way to go.
 
Back
Top