By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,851 Members | 1,160 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,851 IT Pros & Developers. It's quick & easy.

Open a new Form with empty data (new record)

P: n/a
Hello all,

Form A & Form B

Form B opens when I click on a button from Form A. How do I setup Form
B so it will always let me insert new records. Because right know, when
I click on the button from Form A to Form B (onClickEvent), Form B will
open and show all the records that the table has. So I need to click on
the navigation button (buttom of the form) and insert a new record.

Help pleaseee, thanks

Jul 20 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
On 20 Jul 2006 13:12:06 -0700, erick-flores wrote:
Hello all,

Form A & Form B

Form B opens when I click on a button from Form A. How do I setup Form
B so it will always let me insert new records. Because right know, when
I click on the button from Form A to Form B (onClickEvent), Form B will
open and show all the records that the table has. So I need to click on
the navigation button (buttom of the form) and insert a new record.

Help pleaseee, thanks
Code the button click event on FormA:

DoCmd.OpenForm "FormB", , , , acFormAdd
--
Fred
Please respond only to this newsgroup.
I do not reply to personal e-mail
Jul 20 '06 #2

P: n/a

What if I want to add a new record whenever the primary key doesnot
exist (which is working fine, with the code u gave me). But if the
primary key already exist, show the information from that record.

The thing is I am creating this relationship b/w so many tables. Every
single table depends on another one. When I am entering records for my
first table (using a form) it will take me to the next step (pressing
the button) and then to the next step and so forth. This works fine
(add new record) when the record does not exist, but when the record
already exist I will like to look (when I press the button to go to the
next form) to the linked information

Jul 21 '06 #3

P: n/a
Personally, I'd use subforms for this. if you set the LinkChild and
LinkMaster fields, then you don't have to deal with any of this junk.
The UI does it for you. You can just run a filter-by-form on the main
form to find the record you want. If it's not there, you can just add
it. I suppose I could push my car up a hill, but it's much easier to
just get in and drive the thing...

Jul 22 '06 #4

P: n/a

pi********@hotmail.com wrote:
Personally, I'd use subforms for this. if you set the LinkChild and
LinkMaster fields, then you don't have to deal with any of this junk.
The UI does it for you. You can just run a filter-by-form on the main
form to find the record you want. If it's not there, you can just add
it. I suppose I could push my car up a hill, but it's much easier to
just get in and drive the thing...
Thanks for your reply but this is the problem. I have like 20 forms.
Each form is related to the next form. So I dont think I can put 20
forms together using subform, I mean of course you can but it would be
a complete mess. This works fine if you have only 2 forms or maybe 3.
Do you know what I mena?
Thanks for your comment anyways, if you have any other ideas of how I
can do this, please let me know because I am still looking for a
solution

Jul 24 '06 #5

P: n/a
In re: "twenty subforms": You can put an Option Group on the main form,
allowing the user to select the "next form" or "next step" in the process,
and when it is changed, replace the SourceObject of a single Subform Control
with the appropriate Form name.

Otherwise, you need to tell us, where is the PK that you are going to use to
determine whether it exists or not, on the main Form, or somewhere else?
And, when you say, if it exists, do you mean it is not null in the Main
form, or that no Records exist in the RecordSource of the Subform? Is there
a particular order in which the Forms for the related Tables need be opened?

Of course, all this can be done with some behind-the-scenes VBA code, but
the answers to these questions determine what and where that code will be.

Finally, a main Table that has twenty directly-related Tables, would be
rather unusual -- not unheard of, but not common. Perhaps if you explain
what it is you have, and what you are trying to accomplish, someone could
offer an even better approach than just a technical answer.

Larry Linson
Microsoft Access MVP

"erick-flores" <ch**********@hotmail.comwrote in message
news:11*********************@i42g2000cwa.googlegro ups.com...
>
pi********@hotmail.com wrote:
>Personally, I'd use subforms for this. if you set the LinkChild and
LinkMaster fields, then you don't have to deal with any of this junk.
The UI does it for you. You can just run a filter-by-form on the main
form to find the record you want. If it's not there, you can just add
it. I suppose I could push my car up a hill, but it's much easier to
just get in and drive the thing...

Thanks for your reply but this is the problem. I have like 20 forms.
Each form is related to the next form. So I dont think I can put 20
forms together using subform, I mean of course you can but it would be
a complete mess. This works fine if you have only 2 forms or maybe 3.
Do you know what I mena?
Thanks for your comment anyways, if you have any other ideas of how I
can do this, please let me know because I am still looking for a
solution

Jul 24 '06 #6

P: n/a

Larry Linson wrote:
In re: "twenty subforms": You can put an Option Group on the main form,
allowing the user to select the "next form" or "next step" in the process,
and when it is changed, replace the SourceObject of a single Subform Control
with the appropriate Form name.

Otherwise, you need to tell us, where is the PK that you are going to use to
determine whether it exists or not, on the main Form, or somewhere else?
And, when you say, if it exists, do you mean it is not null in the Main
form, or that no Records exist in the RecordSource of the Subform? Is there
a particular order in which the Forms for the related Tables need be opened?

Of course, all this can be done with some behind-the-scenes VBA code, but
the answers to these questions determine what and where that code will be.

Finally, a main Table that has twenty directly-related Tables, would be
rather unusual -- not unheard of, but not common. Perhaps if you explain
what it is you have, and what you are trying to accomplish, someone could
offer an even better approach than just a technical answer.

Larry Linson
Microsoft Access MVP
Sorry about the misunderstanding. Let me try to give a better
explanation

I am creating an interface name: Compressor Survey Application

The database has 18 tables. Each table has in avg 9-11 fields. Some of
the table names are: Locations, Compressors, Stages, Cylinders,
Gaskets, Case Parts, etc

The application works like this: Load the Location form, fill the form
and click on a button that says "Compressors". The compressors form
opens, the location_pk is link to the compressors Form (location_fk).
Then you fill this form and click on a button that says: "Stages", The
stages Form opens, the compressor_pk is link to the stages Form
(stages_fk). Then you fill this form and click on "Cylinders"....the
same procedure here. This is how it works. A pk is always carry to the
next form as the fk for that form.

Right now it is all working good. I have some VBA code behind each of
my forms. When I open each form, by clicking on a button, the form
loads as acFormAdd. I did this so I can add new information
automatically, which works fine when is a new pk. But if I want to,
lets say for instance, update a record or just see the information that
i've entered was correct or not, I want to click on the button that
takes me to the next form and see my old record information. Think
about like an IF statement, where if pk = new then acFormADD else
show_old_record

Please let me know what you think, and if you have any ideas

Thank you

Jul 24 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.