Form not showing data from tables

[marylipscomb]

I am new at the whole Access thing, and recently got a new job. I am creating my first database. I did so in Access 2003. My problem is, I have 10 tables, and I created a tab form with 6 tabs on it. When I enter data on the form/subforms I go out of it and go back into, all my data in the forms are gone. They are in the table though. Can someone please help me. I am sooo new to all this.
It is saving to the table but not the subforms. It is also saving it to the main forms that I created the subforms from. HELP PLEASE!! thanks.

[Rabbit]

Check the forms that the subform object uses as a source and make sure those form's record source property is bound to the correct tables.

[marylipscomb]

I will do that, thank you very much for your reply!!!!!

[Rabbit]

Not a problem, let us know how you get along.

[marylipscomb]

They all seem to match up the way they should. Do you think it might have something to do with the fact that I have relationships but they are not one-many relationships, they are just the straight lines connecting the fields?

Sorry, I really am a complete newbie with this stuff.

Thanks

[marylipscomb]

And also, I have each table linked table to table, should I have all the subforms be linked by the relationship just to the main form instead of main table to first subform, then that subform to the next subform, then the next..?
I hope it is clear what I am asking.

[Rabbit]

Just to be clear, do you know that a tab and subform are different things entirely? A tab is not bound to any table, you can only do that with a subform. The tab just let's you spread things over several pages.

The relationships only matter in a form/subform if there are linked fields that you need to carry over. The main form should consist of a primary key and should be unique. The subform should have a corresponding foreign key that doesn't have to be unique.

[marylipscomb]

Just to be clear, do you know that a tab and subform are different things entirely? A tab is not bound to any table, you can only do that with a subform. The tab just let's you spread things over several pages.

The relationships only matter in a form/subform if there are linked fields that you need to carry over. The main form should consist of a primary key and should be unique. The subform should have a corresponding foreign key that doesn't have to be unique.

No I didn't know that, I thought you had to put a subform on a tab page. Interesting. I think the whole relationship thing is really messing me up. I just created a whole new database to try again and it still isn't working. I create a form, then put a subform on that page, and when I try to enter data on the subform (on that page) it gives me an error. But I can enter the info on the main form on that page.

The error is "You can't assign a value to this object.
*The object may be a control on a read-only form.
*The object may be on a form that is open in Design view.
*The value may be too large for this field."

I know it can't be the middle choice it gives. But I can't find where it might be read-only, and really dont think it is. I don't think it is the last choice either. So I don't know why it is saying that. That was a problem I had with the last database too.

When you say the subform should have a corresponding foreign key that doesn't have to be unique, do you mean that this doesn't have to be an identical name in the form? Like for example,in an Applicant form, I have ApplicantID as the primary key, so in the subform, I can have ApplicantID and it doesn't have to be a primary key, but can link the two together? What if I have other forms as well, which I do, will they all contain the ApplicantID so they can all link?? But on those they will be considered the foreign key?

Thank you so much!!

[AccessIdiot]

Be careful with the terms "form" and "table". I often confuse the two in posts and it just gets the folks who are trying to help you confused. :)

What Rabbit is getting at here is fundamental to database design. If you want to link your tables together with ApplicantID then make ApplicantID in your Applicant table (also referred to as "Applicant.ApplicantID" [table.fieldname]) an autonumber field and the primary key of the Applicant table. Now in your other tables you can have ApplicantID be a number field and NOT the primary key. In your relationships diagram you can draw the lines between the tables using the ApplicantID. I would recommend checking the boxes for "enforce referential integrity" and the two "cascade updates/deletes". This will help you troubleshoot if you run into problems later. Also, I'm assuming all your relationships are one to many.

Now all your tables are tied by the ApplicantID. If you have a form that has a control source of the Applicant table and a subform that has a control source of a different table that contains ApplicantID then the two should be tied together by that field.

Hope this helps.

[marylipscomb]

Be careful with the terms "form" and "table". I often confuse the two in posts and it just gets the folks who are trying to help you confused. :)

What Rabbit is getting at here is fundamental to database design. If you want to link your tables together with ApplicantID then make ApplicantID in your Applicant table (also referred to as "Applicant.ApplicantID" [table.fieldname]) an autonumber field and the primary key of the Applicant table. Now in your other tables you can have ApplicantID be a number field and NOT the primary key. In your relationships diagram you can draw the lines between the tables using the ApplicantID. I would recommend checking the boxes for "enforce referential integrity" and the two "cascade updates/deletes". This will help you troubleshoot if you run into problems later. Also, I'm assuming all your relationships are one to many.

Now all your tables are tied by the ApplicantID. If you have a form that has a control source of the Applicant table and a subform that has a control source of a different table that contains ApplicantID then the two should be tied together by that field.

Hope this helps.

It does help a lot, but came across a problem. I did everything you said and made the ApplicantID the primary key and autonumber in the table, and made the ApplicantID a number field in the remaining tables but when I try to connect them with relationships and check the boxes for "enforce referential integrity" and the two "cascade updates/deletes" a box pops up and says "Relationship must be on the same number of fields with the same data types." I don't think it likes the first ApplicantID being a autonumber and the rest of them being number fields.

Thanks for your help. I appreciate it!!!

[AccessIdiot]

No that shouldn't be a problem but check the number type. It needs to be an integer and not something with a decimal.

[marylipscomb]

No that shouldn't be a problem but check the number type. It needs to be an integer and not something with a decimal.

I checked them all and they are all integers. hmmm wonder why it is giving me that error message then.

[marylipscomb]

aah, nevermind, found that, They have to having matching Fieldsizes if one is an autonumber and the other is a number.

Thanks for all your help. Hopefully this will solve all my problems!!

[AccessIdiot]

Yes, the field size is where you set it to be long integer, short integer, single, double, etc. :)

[marylipscomb]

Yes, the field size is where you set it to be long integer, short integer, single, double, etc. :)

Thank you so much!!!

[Rabbit]

Nice job Melissa.

[AccessIdiot]

Glad to help for once! :)

[Denburt]

Impressive, nice job Melissa.

[Denburt]

Oh and WTG Mary glad you got it.