Please help

[mjones]

Hi All,

I'm a new poster and could really use help. I'm working on upgrading
my learn-as-you-go Access skills to update my small business
application. I've just done Microsoft's online courses for Access
2003. Yes I know, I'm still in the dark ages and probably didn't take
the best course because it didn't provide enough detail - or I didn't
get it, but it was free.

Here's what I'm trying to do (hope I explain it right). In people
speak, in a fGraduateList form:

1 - Select a clientID from a dropdown (from tClient table)

2 - Find the client's associated classcode (from tClassClient)
(client's only take one class right now so there will only be one, but
there can be more in the future)

3 - Show the classcode on the fGraduateList form, and

4 - Update the tGraduateList table with the classcode.

Info:

fGraduateList form has record source SELECT tGraduateList.* FROM
tGraduateList;

tGraduateList table has fields ClientID (number) and ClassCode (text)

fGraduateList has an object called ClientID with record source
ClientID and row source SELECT tClient.ID, tClient.LName & ", " &
tClient.FNameF AS Expr1 FROM tClient ORDER BY tClient.LName & ", " &
tClient.FNameF; (because it displays the client's name instead of the
ClientID on the form)

tClient table has fields ClientID, FNameF, and LName

tClassClient table has fields ClientID and ClassCode

Then, if I really want to get fancy, I could look up the client's
GraduationDate, show it on the fGraduateList and update the
GraduationDate field in the tGraduateList table. tClass table has
fields ClassCode and GraduationDate so for each ClientID, we can find
their ClassCode in the tClassClient table and then use the ClassCode
to lookup their GraduationDate in the tClass table.

I don't want anyone to feel like I'm trying to get some free work. I
truly hope to learn from this and apply it to future work making a
receipt (almost done until the database became corrupted), invoice and
course confirmation. I'm happy I was able to functionality for course
certificates and a graduation list report. It would just be nice to
have the ClassCode and GraduationDate autopopulate because I know
they're in there.

All the best!

Michele

 

[XPS350]

Why do you want to store the classcode in two places?

Normally you don't do that because there is no need to and there is a risk of errors (different values on the two places).

Now there is just one associated classcode. What will you do when there are more?


Peter
http://access.xps350.com/

 

[mjones]

Why do you want to store the classcode in two places?

Normally you don't do that because there is no need to and there is a risk of errors (different values on the two places).

Now there is just one associated classcode. What will you do when there are more?

Peterhttp://access.xps350.com/

Ah, that makes sense. Okay, let's not get it.

Currently, the ClassCode is in the tGraduateList table because it is
included in the GraduateList report (not previously mentioned). If I
know how to get the ClassCode into the report, I won't need it in the
table or form.

Thanks for your comments,

Michele

 

[John W. Vinson]

Currently, the ClassCode is in the tGraduateList table because it is
included in the GraduateList report (not previously mentioned). If I
know how to get the ClassCode into the report, I won't need it in the
table or form.

You may be making the common mistake of assuming that a Report must be based
on a Table containing all the data you want to see.

This assumption is WRONG.

It's normal to base a Report on a Query joining two or more (sometimes quite a
few more) tables. Each table contributes its own fields to the report.
--

John W. Vinson [MVP]
Microsoft's replacements for these newsgroups:
http://social.msdn.microsoft.com/Forums/en-US/accessdev/
http://social.answers.microsoft.com/Forums/en-US/addbuz/
and see also http://www.utteraccess.com

 

[Phil Hunt]

Did you get to form/subform in your crash course. It may be your best bet to
accomplish what you are trying to do.

Why do you want to store the classcode in two places?

Normally you don't do that because there is no need to and there is a risk
of errors (different values on the two places).

Now there is just one associated classcode. What will you do when there
are more?

Peterhttp://access.xps350.com/

Ah, that makes sense. Okay, let's not get it.

Currently, the ClassCode is in the tGraduateList table because it is
included in the GraduateList report (not previously mentioned). If I
know how to get the ClassCode into the report, I won't need it in the
table or form.

Thanks for your comments,

Michele

 

[mjones]

Did you get to form/subform in your crash course. It may be your best betto






Ah, that makes sense.  Okay, let's not get it.

Currently, the ClassCode is in the tGraduateList table because it is
included in the GraduateList report (not previously mentioned).  If I
know how to get the ClassCode into the report, I won't need it in the
table or form.

Thanks for your comments,

Michele

Hi All,

Thank you everyone for your wisdom. I see design/structure is very
important.

Based on comments, here's a simpler update of what I need help to do:

In a fGraduateList form:

1 – A ClientID (number) is selected from a dropdown (from tClient
table) – this is already done as below
(Note that because above object displays the client's name on the form
instead of the ClientID this ClientID object has a record source
ClientID and row source SELECT tClient.ID, tClient.LName & ", " &
tClient.FNameF AS Expr1 FROM tClient ORDER BY tClient.LName & ", " &
tClient.FNameF; )

2 - Find ClassCode (using unique ClientID above from tClassClient
table),

3 – Find GraduationDate (using unique ClassCode above from tClass
table),

4 – Display GraduationDate in this form’s GraduationDate object, and

5 - Update tGraduateList table with the GraduationDate.

(From what has been said, GraduationDate shouldn’t be duplicated in
tGraduateList (not needed and adds risk) because it can be found using
the above method. However, it’s currently needed in an rGraduate
report (certificate) that gets GraduationDate from this tGraduateList
table. Later, if I can figure out how to change the report to get it
the same way as above, I won’t need it in tGraduateList.)

Yes Phil, I did a lesson on subforms and there are subforms in a
packing slip and a purchase order, neither of which I developed
myself. Please elaborate on how subforms would help accomplish the
objective above.

John, regarding basing a Report on a Query, I have to redo a report
(the last one overloads memory and I can't get into it to attempt a
fix) and I'm going to use the report wizard. I hope that is what you
mean.

By the way John, I tried to find an Access MVP in Ontario Canada to
finish the program. What trouble I had. Apparently, there isn't one
in a city area with over 6 million people - and I'm 5 minutes from
Microsoft Canada's office. The first programmer who started the
database was great, but alas, he liked me, wanted to date me, and I
didn't so we couldn't work together anymore. Then, I hired a girl who
spent a year to do very little and wasted a lot of my time because she
couldn't keep track of requirements. Then, another guy claiming lots
of experience lost some data and didn't follow the requirements
messing everything up. Now, I'm trying to finish the development on
my own after years of frustration. I'm not sure how wise this is
since Access 2003 VBA is apparently becoming an obsolete skill. I do
love Access 2003, however, when it is setup.

Thanks everyone and please don’t give up on me. I’ve learned a lot
already and sorry about the long reply,

Michele

 

[John W. Vinson]

John, regarding basing a Report on a Query, I have to redo a report
(the last one overloads memory and I can't get into it to attempt a
fix) and I'm going to use the report wizard. I hope that is what you
mean.

Not really. I don't find that the wizards are all that clever!

Instead, what I'm suggesting is that you create a Query. Add tClient,
--

John W. Vinson [MVP]
Microsoft's replacements for these newsgroups:
http://social.msdn.microsoft.com/Forums/en-US/accessdev/
http://social.answers.microsoft.com/Forums/en-US/addbuz/
and see also http://www.utteraccess.com

 

[John W. Vinson]

John, regarding basing a Report on a Query, I have to redo a report
(the last one overloads memory and I can't get into it to attempt a
fix) and I'm going to use the report wizard. I hope that is what you
mean.

oops! Sorry, posted too soon.

No. That's not what I mean. I find the wizards to be pretty weak.

Instead, create a Query. Add tClient, tClassClient (joining by ClientID), and
tClassCode (joining by ClassID).

This query now has all of the fields in the three tables, including the client
name and the class name.

Base your report on this Query (use it as the report's Recordsource property
if the report already exists).

You can use any of these fields in the Report. It is NOT NECESSARY to include
the fields in tGraduateList, and I'm guessing it's not necessary to have a
table tGraduateList in your database AT ALL, if all of the fields in it exist
in other tables!
--

John W. Vinson [MVP]
Microsoft's replacements for these newsgroups:
http://social.msdn.microsoft.com/Forums/en-US/accessdev/
http://social.answers.microsoft.com/Forums/en-US/addbuz/
and see also http://www.utteraccess.com

 

[XPS350]

Thank you everyone for your wisdom. I see design/structure is very
important.


(From what has been said, GraduationDate shouldn’t be duplicated in
tGraduateList (not needed and adds risk) because it can be found using
the above method. However, it’s currently needed in an rGraduate
report (certificate) that gets GraduationDate from this tGraduateList
table. Later, if I can figure out how to change the report to get it
the same way as above, I won’t need it in tGraduateList.)

Figure out how to change the report first! That way your (very important indeed) structure can be made OK.

As said by John, you can base the report on query based on the two tables (joined on clientID). No rocket science, just basic design.


Peter
http://access.xps350.com/

 

[mjones]

Figure out how to change the report first! That way your (very important indeed) structure can be made OK.

As said by John, you can base the report on query based on the two tables(joined on clientID). No rocket science, just basic design.

Peterhttp://access.xps350.com/

Thanks everyone! Seems I've been complicating things more than needed
- a good thing because complicated is what it all seems to me at this
time.

I'm expecting delivery of two books today to help (the dummies
series). Trying to get a grasp on how everything is organized, I
looked at the Access Object Model on Microsoft's website and it just
made me realize how many layers one has to understand.

I have to run to class (I teach project management for my own school),
but I'll certainly try your suggestions as soon as I can and let you
know how it goes. It might be Sunday until I get to it because I have
a meeting after class and a class tomorrow, too.

P.S. - Last night, I was thrilled to get the receipt working (after a
two year struggle). There is one nice-to-have left, but I'm sure I
can add it using the example that you're all helping me with here.

 

[John W. Vinson]

I'm expecting delivery of two books today to help (the dummies
series). Trying to get a grasp on how everything is organized, I
looked at the Access Object Model on Microsoft's website and it just
made me realize how many layers one has to understand.

Well, I hope the Dummies books help. What I've seen of them, they're more
tuned to teaching folks to use existing Access applications, more than
designing and developing.

There are lots of good resources though. My friend John Viescas' _Access
<version> Inside Out_ is worth a look; also check out the resources at:

Utter Access discussion forum and resources:
http://www.utteraccess.com

Jeff Conrad's resources page:
http://www.accessmvp.com/JConrad/accessjunkie/resources.html

The Access Web resources page:
http://www.mvps.org/access/resources/index.html

Roger Carlson's tutorials, samples and tips:
http://www.rogersaccesslibrary.com/

A free tutorial written by Crystal:
http://allenbrowne.com/casu-22.html

A video how-to series by Crystal:
http://www.YouTube.com/user/LearnAccessByCrystal

MVP Allen Browne's tutorials:
http://allenbrowne.com/links.html#Tutorials

--

John W. Vinson [MVP]
Microsoft's replacements for these newsgroups:
http://social.msdn.microsoft.com/Forums/en-US/accessdev/
http://social.answers.microsoft.com/Forums/en-US/addbuz/
and see also http://www.utteraccess.com

 

[mjones]

oops! Sorry, posted too soon.

No. That's not what I mean. I find the wizards to be pretty weak.

Instead, create a Query. Add tClient, tClassClient (joining by ClientID),and
tClassCode (joining by ClassID).

This query now has all of the fields in the three tables, including the client
name and the class name.

Base your report on this Query (use it as the report's Recordsource property
if the report already exists).

You can use any of these fields in the Report. It is NOT NECESSARY to include
the fields in tGraduateList, and I'm guessing it's not necessary to have a
table tGraduateList in your database AT ALL, if all of the fields in it exist
in other tables!
--

             John W. Vinson [MVP]
 Microsoft's replacements for these newsgroups:
 http://social.msdn.microsoft.com/Forums/en-US/accessdev/
 http://social.answers.microsoft.com/Forums/en-US/addbuz/
 and see alsohttp://www.utteraccess.com

Hi John,

Thanks for the training links. They'll certainly help. I've been
reading the Dummies books I got yesterday all day and struggling to
understand what you mean by:

Create a Query. Add tClient, tClassClient (joining by ClientID), and
tClassCode (joining by ClassID). Then, use it as the report's
Recordsource property.

As you suggested, I made a query that's now the report's Record
Source, but now I have a mess. The dropdown to select the ClientID
object has the list, but I can't pick anything (i.e. nothing happens
when I enter on an item in the list). Same for the ClassCode object -
list, but can't select and it displays #Name?.

Also, some of the records are lost and some students (ClientIDs) are
repeated two, three, or four times. And now I can't add a new record
to the form, i.e. the >* button is greyed out.

The report's Record Source used to be SELECT tGraduateList.* FROM
tGraduateList; So, I figured I needed to add the tGraduateList to the
query. That helped because I was getting no records before adding
it. (You're probably laughing at my newbiness right now.)

This is what the form's record source query looks like now:

SELECT tClient.*, tClassClient.ClientID, tClassClient.ClassCode,
tGraduateList.*
FROM (tClass INNER JOIN tGraduateList ON tClass.ClassCode =
tGraduateList.ClassCode) INNER JOIN (tClient INNER JOIN tClassClient
ON tClient.ID = tClassClient.ClientID) ON tClass.ClassCode =
tClassClient.ClassCode;

Any ideas on how to get the ClientID and ClassCode lists to work
again, etc. would be greatly appreciated.

All the best,

Michele

 

[John W. Vinson]

Hi John,

Thanks for the training links. They'll certainly help. I've been
reading the Dummies books I got yesterday all day and struggling to
understand what you mean by:

Create a Query. Add tClient, tClassClient (joining by ClientID), and
tClassCode (joining by ClassID). Then, use it as the report's
Recordsource property.

As you suggested, I made a query that's now the report's Record
Source, but now I have a mess. The dropdown to select the ClientID
object has the list, but I can't pick anything (i.e. nothing happens
when I enter on an item in the list). Same for the ClassCode object -
list, but can't select and it displays #Name?.

Also, some of the records are lost and some students (ClientIDs) are
repeated two, three, or four times. And now I can't add a new record
to the form, i.e. the >* button is greyed out.

The report's Record Source used to be SELECT tGraduateList.* FROM
tGraduateList; So, I figured I needed to add the tGraduateList to the
query. That helped because I was getting no records before adding
it. (You're probably laughing at my newbiness right now.)

This is what the form's record source query looks like now:

SELECT tClient.*, tClassClient.ClientID, tClassClient.ClassCode,
tGraduateList.*
FROM (tClass INNER JOIN tGraduateList ON tClass.ClassCode =
tGraduateList.ClassCode) INNER JOIN (tClient INNER JOIN tClassClient
ON tClient.ID = tClassClient.ClientID) ON tClass.ClassCode =
tClassClient.ClassCode;

Any ideas on how to get the ClientID and ClassCode lists to work
again, etc. would be greatly appreciated.

All the best,

Michele

I'm sorry, I'm not communicating clearly.

A FORM is one thing.

A REPORT is another, a different, thing.

You would use a Form (probably with subforms) to *enter data* into your
tables. Each form/subform would be based probably on a single table (you can
use two-table queries in some instances but at the beginning level, just one).

You would use a Report to *PRINT* data onto paper. The Report would - often,
I'd even say usually - be based on a multitable query.

If you read badk through the thread you'll see that I suggested basing the
REPORT on a multitable query. I didn't intend that to mean that you should use
the same query for the Form, or that you try to use it to enter data; my
apologies if that's what came across!

Go back to your form which was working. It seems to be getting the data into
the tables correctly (or if it's not, I'm sure it's fixable). Use the
suggested query - or, again, a fixed version of it - as the recordsource of
your Report.
--

John W. Vinson [MVP]
Microsoft's replacements for these newsgroups:
http://social.msdn.microsoft.com/Forums/en-US/accessdev/
http://social.answers.microsoft.com/Forums/en-US/addbuz/
and see also http://www.utteraccess.com

 

[mjones]

I'm sorry, I'm not communicating clearly.

A FORM is one thing.

A REPORT is another, a different, thing.

You would use a Form (probably with subforms) to *enter data* into your
tables. Each form/subform would be based probably on a single table (you can
use two-table queries in some instances but at the beginning level, just one).

You would use a Report to *PRINT* data onto paper. The Report would - often,
I'd even say usually - be based on a multitable query.

If you read badk through the thread you'll see that I suggested basing the
REPORT on a multitable query. I didn't intend that to mean that you should use
the same query for the Form, or that you try to use it to enter data; my
apologies if that's what came across!

Go back to your form which was working. It seems to be getting the data into
the tables correctly (or if it's not, I'm sure it's fixable). Use the
suggested query - or, again, a fixed version of it - as the recordsource of
your Report.
--

             John W. Vinson [MVP]
 Microsoft's replacements for these newsgroups:
 http://social.msdn.microsoft.com/Forums/en-US/accessdev/
 http://social.answers.microsoft.com/Forums/en-US/addbuz/
 and see alsohttp://www.utteraccess.com

Hi John,

Please don't apologize. I soooo appreciate your help.

I've moved the query to the report. Now there's an error that
GraduationDate could refer to more than one table in the FROM clause.

Yes, I'm doing a bad thing and having the GraduateDate field
duplicated in the tClass table and the tGraduateList table, but that's
because it's possible that someone missed the last day and made up the
class on a later date, thus having a different graduation date than
the rest of their class (important for income tax stuff).

Thus, what I'm trying to have the form default GraduationDate frrom
the tClass table and then, in this rare occasion, one could change the
date. The GraduationDate, changed or not, would go into the
tGraduateList table and and also appear on the tCertificate form
(graduate certificate).

Is there a way to update this statement (as Record Source for the
form) to avoid the error? The tCertificate report works fine, I just
thought it was unnecessary for my assistant to have to input the date
when it's already in the database. Isn't that the whole idea of
moving from Excel to Access, which is what I'm doing, to avoid
duplicating data.

SELECT tClient.*, tClassClient.ClientID, tClassClient.ClassCode,
tGraduateList.* FROM (tClass INNER JOIN tGraduateList ON
tClass.ClassCode = tGraduateList.ClassCode) INNER JOIN (tClient INNER
JOIN tClassClient ON tClient.ID = tClassClient.ClientID) ON
tClass.ClassCode = tClassClient.ClassCode;

Thanks a bunch!

Michele

 

[mjones]

Hi John,

Please don't apologize.  I soooo appreciate your help.

I've moved the query to the report.  Now there's an error that
GraduationDate could refer to more than one table in the FROM clause.

Yes, I'm doing a bad thing and having the GraduateDate field
duplicated in the tClass table and the tGraduateList table, but that's
because it's possible that someone missed the last day and made up the
class on a later date, thus having a different graduation date than
the rest of their class (important for income tax stuff).

Thus, what I'm trying to have the form default GraduationDate frrom
the tClass table and then, in this rare occasion, one could change the
date.  The GraduationDate, changed or not, would go into the
tGraduateList table and and also appear on the tCertificate form
(graduate certificate).

Is there a way to update this statement (as Record Source for the
form) to avoid the error?  The tCertificate report works fine, I just
thought it was unnecessary for my assistant to have to input the date
when it's already in the database.  Isn't that the whole idea of
moving from Excel to Access, which is what I'm doing, to avoid
duplicating data.

SELECT tClient.*, tClassClient.ClientID, tClassClient.ClassCode,
tGraduateList.* FROM (tClass INNER JOIN tGraduateList ON
tClass.ClassCode = tGraduateList.ClassCode) INNER JOIN (tClient INNER
JOIN tClassClient ON tClient.ID = tClassClient.ClientID) ON
tClass.ClassCode = tClassClient.ClassCode;

Thanks a bunch!

Michele

I'm struggling with this so much. I'm sure it's not rocket science
and that I'm missing a fundamental concept. On the other hand, I've
been looking at this so long, I might be going loonie.

The last piece to get a functioning receipt is putting class dates,
(e.g.October 15, 22 & 29 and November 5 & 12, 2011) into the ClassDate
object on the rReceipt report. The report Record Source, although
probably not done well, is:

SELECT tReceipt.StudentID, tClient.ID, tReceipt.AmountReceived,
tReceipt.ReceiptNo, tReceipt.ReceiptDate, tReceipt.ReceiptNote,
tReceipt.ClassCode, tClient.*, tReceipt.ReceiptMethod,
tReceipt.CompanyID FROM (tClient INNER JOIN tReceipt ON tClient.ID =
tReceipt.StudentID) INNER JOIN tClass ON tReceipt.ClassCode =
tClass.ClassCode WHERE (((tReceipt.StudentID)=[tClient].[ID]));

The tReceipt table should be able to get it's record's ClassDate
because it has the ClassCode field and the tClass table has a unique
record for each ClassCode field with a corresponding ClassDate field.

This should be a basic thing to do in Access, but alas, I'm feeling
like a failure and should go back to my corner and read the Query
chapter again Can someone help?

Michele

 

[John W. Vinson]

I've moved the query to the report. Now there's an error that
GraduationDate could refer to more than one table in the FROM clause.

That means exactly what it says. The query has two fields named
GraduationDate. You need to specify WHICH graduation date, by using

[Tablename].[GraduationDate]

in the query instead of just [GraduationDate].
--

John W. Vinson [MVP]
Microsoft's replacements for these newsgroups:
http://social.msdn.microsoft.com/Forums/en-US/accessdev/
http://social.answers.microsoft.com/Forums/en-US/addbuz/
and see also http://www.utteraccess.com

 

[mjones]

I've moved the query to the report.  Now there's an error that
GraduationDate could refer to more than one table in the FROM clause.

That means exactly what it says. The query has two fields named
GraduationDate. You need to specify WHICH graduation date, by using

[Tablename].[GraduationDate]

in the query instead of just [GraduationDate].
--

             John W. Vinson [MVP]
 Microsoft's replacements for these newsgroups:
 http://social.msdn.microsoft.com/Forums/en-US/accessdev/
 http://social.answers.microsoft.com/Forums/en-US/addbuz/
 and see alsohttp://www.utteraccess.com

Ah, yes, of course. One should quit when tired.

But putting the Select statement in the report doesn't solve my
problem. The form is the problem.

How can one get a form object default value from a table (record
source?), and then have it populate another table while allowing the
user to change the value in the form's object that goes into the other
table, if they need to change it?

Scrolling up, the real need is to have the form default the
tGraduateList.GraduationDate object seen on the screen from
tClass.GraduationDate and then, allow one to change the date if
needed. The GraduationDate, changed or not, would then go into
tGraduateList.GraduationDate as the actual date, which is then used on
the graduate certificate report, which works fine.

Thanks again!

Michele

 

[mjones]

I've moved the query to the report.  Now there's an error that
GraduationDate could refer to more than one table in the FROM clause.

That means exactly what it says. The query has two fields named
GraduationDate. You need to specify WHICH graduation date, by using

[Tablename].[GraduationDate]

in the query instead of just [GraduationDate].
--

             John W. Vinson [MVP]
 Microsoft's replacements for these newsgroups:
 http://social.msdn.microsoft.com/Forums/en-US/accessdev/
 http://social.answers.microsoft.com/Forums/en-US/addbuz/
 and see alsohttp://www.utteraccess.com

Ah yes, one shouldn't work when tired. But putting the select
statement in the report doesn't solve the problem.

How can one make an object value shown on a form default to a value in
a table, and then put the value in another table, allowing the user to
change it on the form if needed? What is the form object's record
source?

The real need (scroll up), is have the form object
fGraduateList.GraduationDate default from tClass.GraduationDate and
then, if needed, allow one to change the date. The date, changed or
not, then goes into tGraduateList.GraduationDate, which appears on the
graduation certificate form, which works fine.

All the best and thanks again,

Michele

 

[mjones]

That means exactly what it says. The query has two fields named
GraduationDate. You need to specify WHICH graduation date, by using

[Tablename].[GraduationDate]

in the query instead of just [GraduationDate].
--

             John W. Vinson [MVP]
 Microsoft's replacements for these newsgroups:
 http://social.msdn.microsoft.com/Forums/en-US/accessdev/
 http://social.answers.microsoft.com/Forums/en-US/addbuz/
 and see alsohttp://www.utteraccess.com

Ah, yes, of course.  One should quit when tired.

But putting the Select statement in the report doesn't solve my
problem.  The form is the problem.

How can one get a form object default value from a table (record
source?), and then have it populate another table while allowing the
user to change the value in the form's object that goes into the other
table, if they need to change it?

Scrolling up, the real need is to have the form default the
tGraduateList.GraduationDate object seen on the screen from
tClass.GraduationDate and then, allow one to change the date if
needed.  The GraduationDate, changed or not, would then go into
tGraduateList.GraduationDate as the actual date, which is then used on
the graduate certificate report, which works fine.

Thanks again!

Michele

Sorry this appeared twice, the first one didn't show up for 5 or so
minutes so I thought it didn't work and typed it again.

 

[John W. Vinson]

The real need (scroll up), is have the form object
fGraduateList.GraduationDate default from tClass.GraduationDate and
then, if needed, allow one to change the date. The date, changed or
not, then goes into tGraduateList.GraduationDate, which appears on the
graduation certificate form, which works fine.

You'll need to use a macro or (I'd prefer) VBA code in the AfterUpdate event
of the "master" GraduationDate (the one bound to tClass.GraduationDate) set
the other textbox. Guessing that tGraduateList is edited on a subform named
subGraduateList and tClass is on the mainform, the code would be something
like

Private Sub GraduationDate_AfterUpdate()
If IsNull(Me!subGraduateList.Form!GraduationDate) Then
Me!subGraduateList.Form!GraduationDate) = Me!GraduationDate
End If
End Sub

Of course you'll need to adjust the control names to your own.
--

John W. Vinson [MVP]
Microsoft's replacements for these newsgroups:
http://social.msdn.microsoft.com/Forums/en-US/accessdev/
http://social.answers.microsoft.com/Forums/en-US/addbuz/
and see also http://www.utteraccess.com