AfterUpdate

[Guest]

I have a parent form frmDemographics and child form frmVisitIDsubform. On
Parent form I have txtmedicalrecord and on child form I have
txtmedicalrecord1. If I enter a medical record in txtmedicalrecord, what
would the syntax be if I wanted that medical record to show up in
txtmedicalrecord1? Would I put that as AfterUpdate on Parent or Child form?
Thanks for your help in advance.

 

[Dirk Goldgar]

I have a parent form frmDemographics and child form
frmVisitIDsubform. On Parent form I have txtmedicalrecord and on
child form I have txtmedicalrecord1. If I enter a medical record in
txtmedicalrecord, what would the syntax be if I wanted that medical
record to show up in txtmedicalrecord1? Would I put that as
AfterUpdate on Parent or Child form? Thanks for your help in advance.

Is your subform based on a table that is related many-to-one with the
table on which the main form is based? Is the Link Master Field of the
subform the primary key field of the main form's recordsource? That's
the way I'd expect it to be set up, but if it is set up like that, what
is the point of having txtmedicalrecord1 in the subform at all? That
sounds like duplicating information in the "many" table that is present
in the "one" table. In most cases, that's not something you want to do.

Would it ever be the case that txtmedicalrecord1 (on the subform) should
*not* be the same as txtmedicalrecord (on the main form)? That would be
a reason for having the field on the subform. But then you'd need to
define under what circumstances the subform's field should be allowed to
differ.

Can you explain this in more detail?

 

[Guest]

Dirk,

Is your subform based on a table that is related many-to-one with the
table on which the main form is based?

Yes, I have tblDemographics linked to tblVisitID via MedicalRecord. It is a
one-many relationship.

Is the Link Master Field of the
subform the primary key field of the main form's recordsource? That's
the way I'd expect it to be set up, but if it is set up like that, what
is the point of having txtmedicalrecord1 in the subform at all? That
sounds like duplicating information in the "many" table that is present
in the "one" table. In most cases, that's not something you want to do.

Yes, the link master field of the subform is the PK of the main forms
recordsource. I thought I had to have txtmedicalrecord1 in order to use
AfterUpdate. (I am fairly new to this.)

Would it ever be the case that txtmedicalrecord1 (on the subform) should
*not* be the same as txtmedicalrecord (on the main form)? That would be
a reason for having the field on the subform. But then you'd need to
define under what circumstances the subform's field should be allowed to
differ.

They should never be different. As it stands now, on the main form if I
enter a medicalrecord I need to exit out of the form completely and re-open
the form in order for the medicalrecord to appear in the subform. I am
looking for a way to have it automatically appear.

Thank you for the response. Ryan

 

[Dirk Goldgar]

Dirk,


Yes, I have tblDemographics linked to tblVisitID via MedicalRecord.
It is a one-many relationship.



Yes, the link master field of the subform is the PK of the main forms
recordsource. I thought I had to have txtmedicalrecord1 in order to
use AfterUpdate. (I am fairly new to this.)


They should never be different. As it stands now, on the main form if
I enter a medicalrecord I need to exit out of the form completely and
re-open the form in order for the medicalrecord to appear in the
subform. I am looking for a way to have it automatically appear.

Thank you for the response. Ryan

Based on what you tell me, here's how I think you should have it set up.
Your main form should be based on tblDemographics and your subform
should be based on tblVisitID -- not on a query joining the two tables.
I'm going to assume that the medical record number field in both tables
is called "MedicalRecord", but that may not be the case. In
tblDemographics, MedicalRecord is the primary key, while in tblVisitID i
t's a foreign key -- I'm guessing that th primary key of tblVisitID is a
field called VisitID.

Both the main form and the subform should have a control bound to the
MedicalRecord field of their respective recordsource tables. It doesn't
actually matter what these controls are called, but let's assume they
are both called txtMedicalRecord. On the main form, this control should
be visible (its Visible property should be set to Yes), but on the
subform the corresponding control should be invisible -- its Visible
property should be set to No, and you can set its width to 0 and move it
out of the way so you can lay out the other controls without having to
work around it or overlap it. You may or may not want the VisitID field
to be hidden likewise; if it's an autonumber field, you would do well
to hide it from your users.

The Link Master Fields property of the subform control on the main form
should be txtMedicalRecord (referring to the text box on the main form).
The Link Child Fields property should be set to MedicalRecord (referring
to the field in the subform's recordsource table). That ought to take
care of all the linking between the main form and the subform, including
inserting the main form's medical record number in the subform, without
your having to write a line of code.

 

[Guest]

Thank you for the advice, I will try it out and let you know how it works.

Ryan

 

[Guest]

Dirk,
I have a date text box on two subforms of a main form. If I enter a date on
the first subform, is there a way that I can get it to show up on the second?

Ryan

 

[Dirk Goldgar]

Dirk,
I have a date text box on two subforms of a main form. If I enter a
date on the first subform, is there a way that I can get it to show
up on the second?

Yes, but the way you go about it depends on how that second text box
fits into the general scheme of things. Are the two text boxes unbound,
or bound to fields in their respective recordsources, or what? How are
the recordsources of the two subforms related? Is the second text box
*always* supposed to have the same value as the first? If so, what's
the point of storing the information twice? If not, at what point in
the sequence of events is the second text box supposed to be set equal
to the first?

More information, please.

 

[Guest]

Dirk,
After reading your posting I realized that I am making it more difficult for
myself. As I am sure most "new" users do. I have decided to take out the
second text box since there really is no need for the second text box.

Last month I went and bought myself Access 2000: Developers Handbook, as I
move through the book I think I end up getting more confused.

I appreciate the support. Ryan

 

[Dirk Goldgar]

Dirk,
After reading your posting I realized that I am making it more
difficult for myself. As I am sure most "new" users do. I have
decided to take out the second text box since there really is no need
for the second text box.

Last month I went and bought myself Access 2000: Developers Handbook,
as I move through the book I think I end up getting more confused.

<g> It's a terrific book, but fairly advanced -- it tells you how to do
all kinds of things, but not necesarily how to tell whether you should
do them. You may want to use Google Groups to search for
recommendations of more introductory books.

I appreciate the support. Ryan

Glad to help.

 

[Fred Boer]

The Access Developer's Handbook is considered essential by Access
developers, but it still scares the heck out of me, too!! I tend to take it
in short bursts, and only when well rested. <g>

I echo Dirk's suggestion to look for a less, uh, ... *intense* reference
book. There are many out there; I would suggest you go to a bookstore and
check out the available titles - looking at the actual books will help you
decide which one you like. If I can be forgiven making a recommendation, I
would suggest "Running Access xxxx" (Microsoft Press) by Viescas and, for
VBA, "Beginning VBA for Access xxx" by Sussman and Smith (WROX).

And keep hanging around in the newsgroups. Spending a few minutes a day
lurking in here will teach you more than you thought possible. Besides, this
is a *fun* newsgroup... not like those Word and Excel newsgroups.. (g,d and
r).

Cheers!
Fred Boer