table updated only after it is closed

[R Vaughn]

Just a beginner's question, regarding Access 2003:

I created a form that is bound to a table of data. When I add new records
via the form, the assigned table does not display the new records until I
close it, then reopen. I have tried "Refresh" and "Save Record" with no
success. If this is normal (it probably is) with opened tables, then why?
If not, what do I need to do to force the open table to update in real time,
as I complete entering each new record of data through the form? Thanks.

 

[Jack Cannon]

Me.Requery should do the job for you.

Jack Cannon

 

[John W. Vinson]

Just a beginner's question, regarding Access 2003:

I created a form that is bound to a table of data. When I add new records
via the form, the assigned table does not display the new records until I
close it, then reopen. I have tried "Refresh" and "Save Record" with no
success. If this is normal (it probably is) with opened tables, then why?
If not, what do I need to do to force the open table to update in real time,
as I complete entering each new record of data through the form? Thanks.

Why should it matter?

Tables are NOT designed for data presentation or data interaction. If you're
using a form to enter data, use the same form to view and edit the data! You
needn't (in fact shouldn't) have the Table datasheet open at all. Don't worry,
the data is being added to your table, under the hood where it needs to be.

If you have some good reason to be viewing the same data in two modes - via a
bound form, and via a table datasheet - please explain.

 

[John W. Vinson]

Me.Requery should do the job for you.

Jack Cannon

Well... me.requery will indeed requery *the form*. However it won't requery
the (independent) table datasheet, will it? And table datasheets have no
programmable events so I'm not sure how you WOULD requery it.

I think R. Vaughn should just not be worrying about the table datasheet at
all!

 

[R Vaughn]

Why should it matter?

Tables are NOT designed for data presentation or data interaction. If you're
using a form to enter data, use the same form to view and edit the data! You
needn't (in fact shouldn't) have the Table datasheet open at all. Don't worry,
the data is being added to your table, under the hood where it needs to be.

If you have some good reason to be viewing the same data in two modes - via a
bound form, and via a table datasheet - please explain.

Thank you. I thought that keeping the table open was an expedient way to
view all of the records as I entered data for each record via the form. I
built the form to avoid entering the data into the table directly, because of
the nuisance of scrolling across the table to complete each record. However,
I still wanted to occasionally view all of the data as a stacked set of
records in the table.

I think I understand your explanation. I should not use the table directly
for anything other than storage of raw data. Any manipulation (including
viewing) of the data should be done indirectly (via queries, forms, etc), to
avoid any unintentional changes to the reference data. Am I correct?

 

[David W. Fenton]

Well... me.requery will indeed requery *the form*. However it
won't requery the (independent) table datasheet, will it? And
table datasheets have no programmable events so I'm not sure how
you WOULD requery it.

Not true at all. For instance, you can requery an open table with
this:

Screen.ActiveDatasheet.Requery

In fact, if you check Intellisens for Screen.ActiveDatasheet, you'll
see a whole host of events. You could use them all quite handily if
you wrapped Screen.ActiveDatasheet in a standalone class module.

I think R. Vaughn should just not be worrying about the table
datasheet at all!

I agree about that, though.

 

[John W. Vinson]

Thank you. I thought that keeping the table open was an expedient way to
view all of the records as I entered data for each record via the form. I
built the form to avoid entering the data into the table directly, because of
the nuisance of scrolling across the table to complete each record. However,
I still wanted to occasionally view all of the data as a stacked set of
records in the table.

I think I understand your explanation. I should not use the table directly
for anything other than storage of raw data. Any manipulation (including
viewing) of the data should be done indirectly (via queries, forms, etc), to
avoid any unintentional changes to the reference data. Am I correct?

Not only for that reason, which is a good one; but to allow more *user
friendly* interaction with the data. The Table will typically contain one or
more "lookups" - not lookup FIELDS, I hope, but meaningless numeric foreign
keys to lookup tables; these will be meaningless to users. The layout of
fields is inflexible, just a datasheet of multiple columns; you're restricted
in the types of controls you can use, and so on.

If you want to view multiple records onscreen simultaneously but still have
more flexibility in layout and choice of controls, consider a Continuous Form.
This will let you arrange controls (of various types, as appropriate!) in two
or more lines on the screen and still have multiple records displayed. With
good navigation controls (not just the built in nav buttons) you can still
have user-friendly navigation as well. Forms are VERY adaptable and will repay
some effort in developing them.

 

[R Vaughn]

Thank you for your help.

Not only for that reason, which is a good one; but to allow more *user
friendly* interaction with the data. The Table will typically contain one or
more "lookups" - not lookup FIELDS, I hope, but meaningless numeric foreign
keys to lookup tables; these will be meaningless to users. The layout of
fields is inflexible, just a datasheet of multiple columns; you're restricted
in the types of controls you can use, and so on.

If you want to view multiple records onscreen simultaneously but still have
more flexibility in layout and choice of controls, consider a Continuous Form.
This will let you arrange controls (of various types, as appropriate!) in two
or more lines on the screen and still have multiple records displayed. With
good navigation controls (not just the built in nav buttons) you can still
have user-friendly navigation as well. Forms are VERY adaptable and will repay
some effort in developing them.