Populate Form to Edit

Well what we are trying to do is avoid typing in up to 30 or so fields of
repetitive data for the infant's 2nd, 3rd, etc visits. The original questin
was "How can I autopopulate fields with data from 1st visit so we can edit
any new information for 2nd visit, which may only be 5 fields of new info.
But we'd still want each visit to have a full complete form to run statistics
from depebding on the visit date/studies run.

I hope this makes sense!


John W. Vinson wrote:
I see your point, John! Most infants return 4 times, maybe 5 total. (We run
studies with 4 month olds, 6, 8, and 9 or 10 months). I could see this as
[quoted text clipped - 8 lines]
1. Where do I put the VBA code? (On Current, On Load, On Click...etc or am i
WAY off still??

You probably don't need ANY CODE AT ALL.

If you have a Mainform with information about the infant, and a subform based
on a table of Visits, you would need to only *navigate* to the record for that
infant. You don't need to "populate the form" in the sense you're thinking!
Remember, the form is just a movable window displaying data stored in the
table. You can certainly add a very simple combo box to find the record for a
particular infant, and display the data in that record. The Subform would then
let you add information for the first visit... or the second... or the fourth
or whatevever.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...forms/201001/1

On Fri, 22 Jan 2010 21:51:41 GMT, "KateShep via AccessMonster.com"
u57574@uwe wrote:

Well what we are trying to do is avoid typing in up to 30 or so fields of
repetitive data for the infant's 2nd, 3rd, etc visits. The original questin
was "How can I autopopulate fields with data from 1st visit so we can edit
any new information for 2nd visit, which may only be 5 fields of new info.
But we'd still want each visit to have a full complete form to run statistics
from depebding on the visit date/studies run.

Static information pertaining to the infant should NOT BE in the Visits table;
it should be in the "one" side table.

It would really help if you would post a bit more description of the fields in
your tables and their relationships.

You can certainly write code to have any fields that you want defaulting to
the previous entry in this table... but the *very need to do so* strongly
suggests that your tables aren't properly normalized!
--

John W. Vinson [MVP]

The problem is that not much of the info is static, so I'm trying to think of
a solution to avoid entering "potentially" static data, with the option of
changing the data and saving as a new and separate record in the table. All I
really want is to set the default values to the first visit data.

These are some of the fields:
Static fields:
Gestation weeks, Birthdate, Birth order, Birth weight, Birth length, Birth
place, Birth complications, Race, Ethnicity, etc.

(Potentially) changing fields:
Current age, current weight, current height, parents' marital status, parent
education level, work status, caregiver information, caregiver hours, current
medications, history of ear infections, frequency of reading books, watching
tv, etc.

I can see how a Main Form and a subform could help, but I'd still prefer to
have one form that is auto-filled in with default information from the first
visit.

Any suggestions on how to get that going?

Thanks,
Kate




John W. Vinson wrote:
Well what we are trying to do is avoid typing in up to 30 or so fields of
repetitive data for the infant's 2nd, 3rd, etc visits. The original questin
was "How can I autopopulate fields with data from 1st visit so we can edit
any new information for 2nd visit, which may only be 5 fields of new info.
But we'd still want each visit to have a full complete form to run statistics
from depebding on the visit date/studies run.

Static information pertaining to the infant should NOT BE in the Visits table;
it should be in the "one" side table.

It would really help if you would post a bit more description of the fields in
your tables and their relationships.

You can certainly write code to have any fields that you want defaulting to
the previous entry in this table... but the *very need to do so* strongly
suggests that your tables aren't properly normalized!

--
Message posted via http://www.accessmonster.com

Regarding the relationships between the fields/tables... An infant who comes
at 4 months of age will participate in a study ("4-month study"), and "4-
month study" results (looking time in seconds to various stimuli) will be
imported into a table. Study results table will be linked to this "visits"
(or Basic Information) table so we can examine whether results are related to
variables in the table, such as infant's current height or medications. The
same infant will come back at 6 months of age to participate in the "6-month
study", and the visits table will be updated with their more current
information (here is where I'm trying to default values to the first 4-month
visit date), and the new study results will be linked to the new visit
information record to see, again, if there are relationships between the new
results and their new height, weight, etc.

I hope this makes sense..

KateShep wrote:
The problem is that not much of the info is static, so I'm trying to think of
a solution to avoid entering "potentially" static data, with the option of
changing the data and saving as a new and separate record in the table. All I
really want is to set the default values to the first visit data.

These are some of the fields:
Static fields:
Gestation weeks, Birthdate, Birth order, Birth weight, Birth length, Birth
place, Birth complications, Race, Ethnicity, etc.

(Potentially) changing fields:
Current age, current weight, current height, parents' marital status, parent
education level, work status, caregiver information, caregiver hours, current
medications, history of ear infections, frequency of reading books, watching
tv, etc.

I can see how a Main Form and a subform could help, but I'd still prefer to
have one form that is auto-filled in with default information from the first
visit.

Any suggestions on how to get that going?

Thanks,
Kate

Well what we are trying to do is avoid typing in up to 30 or so fields of
repetitive data for the infant's 2nd, 3rd, etc visits. The original questin
[quoted text clipped - 12 lines]
the previous entry in this table... but the *very need to do so* strongly
suggests that your tables aren't properly normalized!

--
Message posted via http://www.accessmonster.com

Update: I incorporated suggestions made above, such as using subforms for
changing information and linking by infant ID and Received Date. I also found
code for "duplicate last record" into form controls at
http://www.allenbrowne.com/ser-24.html


I'm now trying to figure out how to duplicate from last record in a subform
when the LinkChildFields don't match the current record. ie, the Infant ID is
the same for each record, but the Received Date is different, so the code
assumes there is no previous record to duplicate from.

If anyone has any suggestions, I'd really appreciate it!

Thanks,
Kate

KateShep wrote:
Regarding the relationships between the fields/tables... An infant who comes
at 4 months of age will participate in a study ("4-month study"), and "4-
month study" results (looking time in seconds to various stimuli) will be
imported into a table. Study results table will be linked to this "visits"
(or Basic Information) table so we can examine whether results are related to
variables in the table, such as infant's current height or medications. The
same infant will come back at 6 months of age to participate in the "6-month
study", and the visits table will be updated with their more current
information (here is where I'm trying to default values to the first 4-month
visit date), and the new study results will be linked to the new visit
information record to see, again, if there are relationships between the new
results and their new height, weight, etc.

I hope this makes sense..

The problem is that not much of the info is static, so I'm trying to think of
a solution to avoid entering "potentially" static data, with the option of
[quoted text clipped - 26 lines]
the previous entry in this table... but the *very need to do so* strongly
suggests that your tables aren't properly normalized!

--
Message posted via http://www.accessmonster.com