Help me to work my first app. in access

[sendil099]

Hi Guys,
I am new to this forum and new to access.
I have created a form and table for my prj.
but couldn't able to link it.
can you please help me...
plz find the attachment.

FORM
1. ENTER SHORT NAME
2. CHOOSE OPTION
3. GENERATE BUTTON
4. GENERATED TEXT IN TEXT BOX (EX: R1004 & B1433)
5. SAVE BUTTON TO SAVE RECORD TO TABLE
6. SEARCH RECORD BY ENTERING R1004 OR B1433
6. CLEAR BUTTON TO CLEAR THE RECORD
7 EXIT APPLICATION

 

[theDBguy]

Hi. Welcome to the forum. I haven't downloaded your attachment but what do you mean by "couldn't link it?"

 

[The_Doc_Man]

Looks vaguely like a school project. We don't generally do those for you, but if you have a narrow question about some questionable behavior, we offer help. You need to be specific in describing any such behavior.

For future reference, questions of this type belong under "General" most of the time.

 

[Mark_]

The normal way you develop a database is by defining what data you will work with and how it is related. As such, you would design your tables and their relationship BEFORE working on a form.

Once you have your tables defined, you would set up a query that allows you to work with subsets of either records, fields, or both, that you will want for data entry/update.

You would then base a form off of one of your queries and add the fields from the query to your form. This will make sure they are "connected".

Is this about how you created your project? Or did you create the form first and try to work out a table that matches it?

 

[pbaldy]

For future reference, questions of this type belong under "General" most of the time.

Agree and moved thread.

 

[Mike375]

The normal way you develop a database is by defining what data you will work with and how it is related. As such, you would design your tables and their relationship BEFORE working on a form.

Once you have your tables defined, you would set up a query that allows you to work with subsets of either records, fields, or both, that you will want for data entry/update.

You would then base a form off of one of your queries and add the fields from the query to your form. This will make sure they are "connected".

Is this about how you created your project? Or did you create the form first and try to work out a table that matches it?

As above.

Plus Select queries allow for fields to be created that are calculations or functions. A very simple example would be if the table had a field for FirstName and a field for LastName a field could be created in the query where the two names were joined as in John Smith and that could be displayed on a form.

 

[Cronk]

To "link" the form to the table, you need to set the form's recordsource to that table (or a query based on the table). You also need to set the control source to the corresponding field in the table.
Also, as Date is a reserved word in Access, change the name of your field to ProjectDate or similar.

 

[Pat Hartman]

I looked at the database.
1. there is an error when it opens because the form that is set as the opening form was removed or had it's name changed so this needs fixing.
2. The form is not bound to a RecordSource. Use the dropdown to select a table or query.

3. Since the form itself is not bound, none of the controls are bound. To bind each control, use the same method for each control except, you will be seeing a property called ControlSource and you will be picking a field from whatever recordsource was bound to the form.

In the future or starting now, you might consider using the wizard to build the forms initially. You choose a table or query and the wizard will place all the fields on the form using the layout style you selected. Once the controls are all added, you can rearrange them artistically. I've been using Access for 25+ years and still start most bound forms with the wizard. I generally bind my forms to queries so I select only the columns I want for the form. The forms made by the wizard leave a lot to be desired but itdoes load all selected columns and bind them so it does save work. Plus the controls end up with meaningful names rather than Text39 and Frame53 since that will come back to bite you when you begin writing code. Are you really going to know next month or even next week what Text39 is on formX?

Another object naming suggestion is to use prefixes for objects so your command buttons would be named - cmdGenerate, cmdSave, etc That will make them easier to identify in code. I also would not use all caps in object names. And finally, my preference is to use CamelCase rather than the_underscore as a method of highlighting words. And my preference is very simply because the underscore requires using the shift key and taking your hands off the home row. Once you declare a variable or object name using CamelCase, you never have to use the shift key again, the editor automatically auto corrects camelcase to CamelCase which is a visual clue that you haven't made a typo.