Auto update date in table - not form

[MartyO]

I know how to set up a form to auto populate a date field based on info
entered into another field on the form.
But if I want to do that on the table itself, how do I do it.
For example, when the user types in the data for Qty Ordered, I want it to
auto populate todays date in the Date Ordered field. I can do it on a form,
but they are editing the table.

Thanks in advance!
Marty

 

[S.Clark]

There are two types of database developers...

a) Those that allow users to update tables directly, and
b) those that are sorry they ever allowed users to update tables directly.

Good luck.

 

[John W. Vinson]

I know how to set up a form to auto populate a date field based on info
entered into another field on the form.
But if I want to do that on the table itself, how do I do it.
For example, when the user types in the data for Qty Ordered, I want it to
auto populate todays date in the Date Ordered field. I can do it on a form,
but they are editing the table.

You can't.

Tables have no usable events.

This is just one of many reasons that users should NEVER be entering data in
table datasheets. Another is that it would take three keystrokes (ctrl-A,
<Delete>, <Enter>) to destroy all the data in your table, and there'd be no
way to prevent it.

 

[MartyO]

Agreed. But when you come in after the fact, sometimes baby steps are needed
to move in the right direction. We're getting there slowly.

 

[David W. Fenton]

Tables have no usable events.

Again, another case where someone ignores the capabilities of a
datasheet.

While it's true that a table has not events, when you view a table
as a *datasheet*, it has all the events of a datasheet *form*. It is
accessible via Screen.ActiveDatasheet, and is, effectively, almost
identical to a bound form object in terms of properties/methods. You
can also refer to the fields in the datasheet as you would to
controls on a form, and those, too have their own events.

Now, obviously, you can't save code behind the events as you can
with a form, but you can create a standalone class module for each
table that would do the same thing. The only thing is that it would
be pretty complex to switch between multiple datasheets.

I'm not *recommending* that someone do any of these things.

I'm just pointing out that categorical statements about "tables
having no usable events" are just not true in any meaninful sense.

 

[Douglas J. Steele]

Again, another case where someone ignores the capabilities of a
datasheet.

While it's true that a table has not events, when you view a table
as a *datasheet*, it has all the events of a datasheet *form*. It is
accessible via Screen.ActiveDatasheet, and is, effectively, almost
identical to a bound form object in terms of properties/methods. You
can also refer to the fields in the datasheet as you would to
controls on a form, and those, too have their own events.

Now, obviously, you can't save code behind the events as you can
with a form, but you can create a standalone class module for each
table that would do the same thing. The only thing is that it would
be pretty complex to switch between multiple datasheets.

I'm not *recommending* that someone do any of these things.

I'm just pointing out that categorical statements about "tables
having no usable events" are just not true in any meaninful sense.

But won't what you're describing would only work in Access? If you were
interacting with the table from outside of Access, you wouldn't get that
behaviour, would you?

 

[Larry Linson]

Agreed. But when you come in after the fact,
sometimes baby steps are needed to move in
the right direction. We're getting there slowly.

Baby steps are inappropriate when someone has done something dangerous that
needs to be changed, not later but RIGHT NOW. Would not the application
owner/sponsor think the possibility of losing all data in a table in just
three clicks was "dangerous"? If you are concerned they will think this is
just your own imagination, show them the response from John Vinson. John, by
the way, is a Microsoft MVP for Access, whose information you can show the
owner/sponsor at mvp.support.microsoft.com if they question _his_
credentials.

Larry Linson
Microsoft Office Access MVP

 

[David W. Fenton]

But won't what you're describing would only work in Access? If you
were interacting with the table from outside of Access, you
wouldn't get that behaviour, would you?

Of course you would, because you're viewing it in a datasheet.
Remember, we actually have no raw interaction with a table -- table
view is mediated by the datasheet. If you have a linked table, and
view it in a datasheet, you have all the datasheet events available
to you.

However, I'd never do it that way, as it's not worth it -- I'd
create a datasheet form and use that, since then I wouldn't need a
standalone class module to bind events to it. The only drawback
there is that changes to the table don't automatically propagate
(e.g., new fields, changed field names), whereas they obviously do
with a table datasheet.

 

[Douglas J. Steele]

Of course you would, because you're viewing it in a datasheet.
Remember, we actually have no raw interaction with a table -- table
view is mediated by the datasheet. If you have a linked table, and
view it in a datasheet, you have all the datasheet events available
to you.

But I said "from outside of Access". You can't use a datasheet from, say,
Excel or VB can you?

 

[David W. Fenton]

But I said "from outside of Access". You can't use a datasheet
from, say, Excel or VB can you?

I've gone back through the thread and see no evidence that the OP
was using anything other than Access. Maybe I'm missing some posts
somewhere?