UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Field Names From Table, Access 2016    
 
   
nickynoo
post Nov 5 2017, 11:44 AM
Post#1



Posts: 255
Joined: 18-July 11
From: South Africa


Hi

Ive just created a form in access 2016, now to save me the trouble of trying to look in two places I would like to get those field names into an access table. Is this possible and if so how? I know I should have done it the other way around - Table and then form.

Thanks in advance.

--------------------
Nick

Trying my best but access is very confusing. All roads apparently lead to Rome but some lead to junction tables.
Go to the top of the page
 
orange999
post Nov 5 2017, 12:59 PM
Post#2



Posts: 1,713
Joined: 10-February 08
From: Ottawa, Ont, Canada; West Palm Beach, FL


What 2 places are you talking about exactly -
" look in two places"?

If you have an unbound form with a number of controls, those controls have names. Depending on which controls you are interested in, you might use those name(s) to populate your table.
But I agree, your working from the "back of the cart heading toward the horse".
Good luck.

--------------------
Good luck with your project!
Go to the top of the page
 
GroverParkGeorge
post Nov 5 2017, 01:46 PM
Post#3


UA Admin
Posts: 31,195
Joined: 20-June 02
From: Newcastle, WA


Have you invested some time in learning how relational databases like Access work?

To put your current strategy into an analogy, what you are doing is something like building a house from the roof down, rather than from the foundation up. While it might be possible, it's certainly going to be a LOT harder that way, and unstable in the bargain.

--------------------
Go to the top of the page
 
projecttoday
post Nov 5 2017, 02:16 PM
Post#4


UtterAccess VIP
Posts: 8,674
Joined: 10-February 04
From: South Charleston, WV


Usually table field names are more concise than form labels. For example the label on the form says "Street Address" for a field in the table named "StrAdd". So even if you could copy labels from a form to a table, you would not end up with an ideal table.

--------------------
Robert Crouser

My company's website
Go to the top of the page
 
nickynoo
post Nov 5 2017, 03:02 PM
Post#5



Posts: 255
Joined: 18-July 11
From: South Africa


Orange - the two places Im speaking about are 1) the form that Ive created and 2) the table I want to create from it.

Thanks for the help, I guess its impossible.

It was just easier in this instance to plan out how I wanted the form to look before I made the table. I know that its not the way it is supposed to be done, I was merely asking a question, if the form names can be imported into a table. It would save me some time.

--------------------
Nick

Trying my best but access is very confusing. All roads apparently lead to Rome but some lead to junction tables.
Go to the top of the page
 
projecttoday
post Nov 5 2017, 04:06 PM
Post#6


UtterAccess VIP
Posts: 8,674
Joined: 10-February 04
From: South Charleston, WV


What you're doing is not really so far wrong if you see it as the design phase. It's just that the design is usually done with pen and paper or Word or Excel or something.

--------------------
Robert Crouser

My company's website
Go to the top of the page
 
orange999
post Nov 5 2017, 04:22 PM
Post#7



Posts: 1,713
Joined: 10-February 08
From: Ottawa, Ont, Canada; West Palm Beach, FL


I agree with Robert --consider your work with the form to date as "analysis and design" to confirm your "table requirements'.
I'm also from the school of pencil and paper and a model, but I've seen proponents of mocking up forms as first step. It might
be a great way to deal with the UI bits and pieces, but if your tables and relationships don't match your underlying business data
requirements, the prettiest User interface isn't going to resolve a structure problem.

Another way to look at your work to date is --you now have confirmed what data should be in your table or tables.

Good luck with your project.

--------------------
Good luck with your project!
Go to the top of the page
 
GroverParkGeorge
post Nov 5 2017, 09:41 PM
Post#8


UA Admin
Posts: 31,195
Joined: 20-June 02
From: Newcastle, WA


The difference between the proposal to generate a table based on a form, and the use of a form to think through what pieces of data you want to capture, is that the former implies the table will be designed with those fields found on the form, whereas the latter implies that you'll decide which pieces of data you need to store, but not necessarily which table or tables they'll need to be stored in.

--------------------
Go to the top of the page
 
nickynoo
post Nov 5 2017, 11:44 PM
Post#9



Posts: 255
Joined: 18-July 11
From: South Africa


Thanks guys, I intend to start from the table(s) up, is there anyway to capture the lables, etc. I used on the form. Or is my only option to "start from the beginning" as if the form had never been created. I normally use excel to plan a database, this time I made a form, its unusual but so is life, you dont need to colour in the lines all the time.

--------------------
Nick

Trying my best but access is very confusing. All roads apparently lead to Rome but some lead to junction tables.
Go to the top of the page
 
GroverParkGeorge
post Nov 6 2017, 06:58 AM
Post#10


UA Admin
Posts: 31,195
Joined: 20-June 02
From: Newcastle, WA


Actually, I like to think that consistency is the more important attribute when it comes to designing and building consistently reliable tools for business. Save the creativity for those relaxing hours after work when it is time to let your imagination soar on music, painting, dance, or whatever you do that involves "coloring outside the lines".

In this case, sure, you can model the tables on the forms to some extent. Use the forms as guides to setting up tables and fields. You can use the forms as the basis for creating tables, and the controls on the forms as the basis for the fields in those tables. However, you must apply understanding of sound relational table design to that. For example, list boxes or combo boxes are going to be based on related tables, indicating the presence of a foreign key field in the primary table to which that form belongs. The same is true, of course, for subforms.

I don't think there is anything wrong with mocking up the design of the interface first. The problem would be trying to force tables into existence in order to preserve that interface without understanding of the logic of relational data needed.

--------------------
Go to the top of the page
 
Jeff B.
post Nov 6 2017, 07:22 AM
Post#11


UtterAccess VIP
Posts: 9,880
Joined: 30-April 10
From: Pacific NorthWet


To re-cast what George said, the tables in a well-normalized relational database store data. Forms provide a user-interface to the data, but do NOT have to correspond one-to-one to the tables' data structure.

--------------------
Regards

Jeff Boyce
Microsoft Access MVP (2002-2015)

Mention of hardware or software is, in no way, an endorsement thereof. The FTC of the USA made this disclaimer necessary/possible.
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    12th December 2017 - 03:09 AM