I have a form with a field that I want to update from a sub form field if the sub form field contains a record. I have a field of demand No that is sometimes required and sometimes not. If it is required it will show records from the demand in a sub form. I am trying to pull one data field from the sub form to fill in a field on my form.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Pull Info from Sub form
- Thread starter Dilly
- Start date
JerryDennison
IS-IT--Management
How are you going to define which record in the subform controls the field on your mainform. I think you should re-evaluate what you're trying to accomplish. If you'll explain it a little more we might be able to give you some better alternatives.
- Thread starter
- #3
I will try and explain. I have a database that registers equipment awaiting disposal. Some of the equipment has already been included in another database of demands, but some of the disposals are not required to be redemanded. I have a sub report that is controlled from the demand number if it exists. I then have a database with some items with information included in the sub form and some that needs to be typed in. This information is things like Part No, Serial No Description Etc. I am trying to think of a way of creating a report that will contain information from both the subform and the table. The item details I mean. I thought since i have the details fields within the disposals database could there be a way of getting some of the information from the sub form into the form fields. This may even mean I could remove the sub form.
Hope this is a better explanation. I am struggling a bit because I have gone beyond any help within my company.
Dilly
Hope this is a better explanation. I am struggling a bit because I have gone beyond any help within my company.
Dilly
JerryDennison
IS-IT--Management
I'm sorry, but I still don't follow exactly what you're trying to do. Let me give you a little synopsis of relational database design and maybe you can help me help you.
Access uses tables to store information. Each table is comprised of fields. Each field must be assigned a datatype. The datatype determines what the field can hold. As an aid to entering, presenting, and manipulating the data you have at your disposal various tools. These are Forms, Queries, Reports, Macros, and Modules. Each provides different and often overlapping functionality. This provides the "physical" structure of your database and the interface you present the user.
The logical structure of your database is the tables and the entities these tables represent. This is the most important aspect of your database. It defines what your entities are, how they are described, and the relationships between entities (if any). The most important concept to understand in relational database theory is that of entities(typically this is a table) and descriptors (sometimes called attributes). An entity is a physical or logical construct that cannot be broken down into smaller components without destroying it's integrity. Larger entities can be made up of many smaller entities. A good example is a car. An automobile is made up of many parts but the entire package is a single individual entity and even has an identifying number associated with it (as does almost all of the components that make the car what it is).
In the database world, an entity is normally defined as a table.
Descriptors are adjectives that describe some attribute of the entity. In our example of the car, applicable descriptors would be year of manufacture, location of manufacture, color, make, model, etc.
In the database world, a descriptor is a field in the entity table.
It is very important that descriptors be attributes of the key, the whole key, and nothing but the key. This is another vital concept in relational database theory. The key. Sometimes called the Primary Key. This is a unique identifier for the entity record. It is also the means of relating one entity to another. There are three types of relationships between entities: One-To-One, One-To-Many, and Many-To-Many. True One-To-One relationships are very rare, I'm not going to go into detail for this type of relationship.
One-To-Many: This is the most common relationship you'll deal with when building database applications. As the name implies, for any one record in one table you have many related records in another table. The best way to visualize this is with parents and children. A parent can have many children but a child can have only one set of parents (i.e only one father and only one mother). In database terms the parent/child isn't a good example because you would use a recursive join (join the table to itself) for handling parent/child relationships rather than two seperate tables. But the concept is the same.
Many-To-Many: This is a less common but very useful relationship that allows many entities in one table to be related to many entities in another table. Access does not support a direct many-to-many relational join. You must use an intermediate or linking table.
Now to the meat of your situation (that I don't fully understand what the problem is), a subform should be a table of related entities or records to ONE record of the mainform. Typically, the same holds true for a subreport (though not necessarily). In any case there is almost always a field that is common to the all the tables that are the recordsources for the main report and sub report(s).
I'm sorry if this is long winded. And forgive me if you already knew all of this. But if you'll rephrase your question with these thoughts in mind I (or someone else) may be able to better assist you.
Access uses tables to store information. Each table is comprised of fields. Each field must be assigned a datatype. The datatype determines what the field can hold. As an aid to entering, presenting, and manipulating the data you have at your disposal various tools. These are Forms, Queries, Reports, Macros, and Modules. Each provides different and often overlapping functionality. This provides the "physical" structure of your database and the interface you present the user.
The logical structure of your database is the tables and the entities these tables represent. This is the most important aspect of your database. It defines what your entities are, how they are described, and the relationships between entities (if any). The most important concept to understand in relational database theory is that of entities(typically this is a table) and descriptors (sometimes called attributes). An entity is a physical or logical construct that cannot be broken down into smaller components without destroying it's integrity. Larger entities can be made up of many smaller entities. A good example is a car. An automobile is made up of many parts but the entire package is a single individual entity and even has an identifying number associated with it (as does almost all of the components that make the car what it is).
In the database world, an entity is normally defined as a table.
Descriptors are adjectives that describe some attribute of the entity. In our example of the car, applicable descriptors would be year of manufacture, location of manufacture, color, make, model, etc.
In the database world, a descriptor is a field in the entity table.
It is very important that descriptors be attributes of the key, the whole key, and nothing but the key. This is another vital concept in relational database theory. The key. Sometimes called the Primary Key. This is a unique identifier for the entity record. It is also the means of relating one entity to another. There are three types of relationships between entities: One-To-One, One-To-Many, and Many-To-Many. True One-To-One relationships are very rare, I'm not going to go into detail for this type of relationship.
One-To-Many: This is the most common relationship you'll deal with when building database applications. As the name implies, for any one record in one table you have many related records in another table. The best way to visualize this is with parents and children. A parent can have many children but a child can have only one set of parents (i.e only one father and only one mother). In database terms the parent/child isn't a good example because you would use a recursive join (join the table to itself) for handling parent/child relationships rather than two seperate tables. But the concept is the same.
Many-To-Many: This is a less common but very useful relationship that allows many entities in one table to be related to many entities in another table. Access does not support a direct many-to-many relational join. You must use an intermediate or linking table.
Now to the meat of your situation (that I don't fully understand what the problem is), a subform should be a table of related entities or records to ONE record of the mainform. Typically, the same holds true for a subreport (though not necessarily). In any case there is almost always a field that is common to the all the tables that are the recordsources for the main report and sub report(s).
I'm sorry if this is long winded. And forgive me if you already knew all of this. But if you'll rephrase your question with these thoughts in mind I (or someone else) may be able to better assist you.
- Thread starter
- #5
JerryDennison
IS-IT--Management
You're welcome. Sorry it was so long winded. 
- Status
