Dragging Value to new records

  • Thread starter Thread starter Tim Leach
  • Start date Start date
T

Tim Leach

What I am doing is creating a record with a case number. I am using a tab
form, when a command button is clicked to add a second contact for the
case, I want to go to a new record. But I want the case number that was
entered on the first tab. Say it was V04-03214, I want that number to post
to the new records also, so I can reference all the contacts for the case
when I make the report. Any Ideas>>>>>>>>>>>>>>>>>>>>>>>

Thanks
Tim
 
Tim,

I guess the stock standard approach to this type of situation is to have
a main form bound to your Cases table, and another form, based on your
Contacts table, as a subform on the main form, with the Case Number as
the Link for the subform, in which case (no pun intended) the correct
case number for the contacts is automatically entered. Will this type
of approach work for you?
 
Tim,

I guess the stock standard approach to this type of situation is to have
a main form bound to your Cases table, and another form, based on your
Contacts table, as a subform on the main form, with the Case Number as
the Link for the subform, in which case (no pun intended) the correct
case number for the contacts is automatically entered. Will this type
of approach work for you?
Click to expand...

It would but I would have to redesign some of the program to make it work.
I wanted to kind of stick to one table, basically because I don't
understand the form-subform stuff. I guess I have not been doing this long
enough yet. So, you recomend useing one table for the case number and one
table for the rest of it, then link them ? Where would I find out about the
form-subform relationships?

Thanks Again
Tim Leach
 
Tim,

This is a big topic. But there is a principle of database design called
normalisation. One of the facets of this principle involves thinking
relationally. This means, among other things, that the real-life
relationships within your actual data should be reflected in the table
structure of the database. In your example, your reality is that there
can be more than one Contact for each Case. This means there is a
one-to-many relationship between Cases and Contacts. This means that
these entities should be stored in separate tables, linked via the data
in common which is typically the unique identifying field in the table
on the "one" side of the relationship. The power and flexibility that
this provides is one of the key advantages of using a data management
programme like Access. If you don't use relational principles, then you
might as well not use Access.

So, my recommendation was not really to "use one table for the case
number and one table for the rest of it". There would, I imagine, be
other data elements which are 1:1 with the case. For example, there may
be a case description, date case opened, case manager, etc, all of which
there is only one for each case, these fields would be in the Cases
table. And then it is the contact information that goes in the related
"many" table, only because this is the example of where there can be
more than one of this type of data for each case.

Here is an article which may help:
http://support.microsoft.com/?id=283878
Note the link within this article to a very good webcast on the topic.
 
Tim,

This is a big topic. But there is a principle of database design called
normalisation. One of the facets of this principle involves thinking
relationally. This means, among other things, that the real-life
relationships within your actual data should be reflected in the table
structure of the database. In your example, your reality is that there
can be more than one Contact for each Case. This means there is a
one-to-many relationship between Cases and Contacts. This means that
these entities should be stored in separate tables, linked via the data
in common which is typically the unique identifying field in the table
on the "one" side of the relationship. The power and flexibility that
this provides is one of the key advantages of using a data management
programme like Access. If you don't use relational principles, then you
might as well not use Access.

So, my recommendation was not really to "use one table for the case
number and one table for the rest of it". There would, I imagine, be
other data elements which are 1:1 with the case. For example, there may
be a case description, date case opened, case manager, etc, all of which
there is only one for each case, these fields would be in the Cases
table. And then it is the contact information that goes in the related
"many" table, only because this is the example of where there can be
more than one of this type of data for each case.

Here is an article which may help:
http://support.microsoft.com/?id=283878
Note the link within this article to a very good webcast on the topic.
Click to expand...

Thanks Steve, I think I understand it now and looked up that article.
 
Back
Top