How do I save the date a record was last modified in Access 2003
in [Tables]
|
Prev: auto number
Next: Blank Field in Form
From: Al Campagna on 28 Dec 2009 17:41 David, Of course... but, I use templates with common code already built in, so I just have the DOC code in the "canned" BeforeUpdate code. I don't have to enter a Default for DOC... Regarding your comment about capturing Date instead of Now, it's usually preferable to capture Now... but just display Date format. If an active and busy DB, which might have multiple edits within a day... it's better to capture Now. So I think it's more a case of... why guess whether Date is sufficient... just do Now, and you're always OK. -- Al Campagna Microsoft Access MVP http://home.comcast.net/~cccsolutions/index.html "Find a job that you love... and you'll never work a day in your life." "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9CEFA821AE08Cf99a49ed1d0c49c5bbb2(a)74.209.136.100... > "Al Campagna" <newsgroups(a)comcast.net> wrote in > news:uPnQ9G8hKHA.5520(a)TK2MSFTNGP06.phx.gbl: > >> They each demostrate how to capture the DOC (Date of Creation) >> and >> the DOLE (Date of Last Edit) for each record. > > Date of Creation requires only a default value, no? > > -- > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Clifford Bass via AccessMonster.com on 28 Dec 2009 18:03 Hi, I find setting the default values for date/time fields in Access to Date (), Now() or Time() to be highly inaccurate because the value is set when the new row is displayed, not when data is initially being entered and not when it is actually saved. So if I go to a new record on 12/28/2009 at 11:50 pm, but do not actually start entering anything until 12/29/2009 at 12:15 am and do not actually save it until 12/29/2009 at 12:45 am, it will save with a creation date of 12/28/2009 and a creation time of 11:50 pm. Which is just plain wrong. So the use of the Before Insert event to set it at the time of starting the record is a better solution. Likewise the use of the Before Update event to set it at the time of saving. It would depend on what you are defining as the creation date/time. The default values would be useful for situations where you are importing data; then you would not have to set the creation date/time explicitly. Of course, the whole issue can be complicated further by an inaccurate computer clock. So I could be entering data on a computer with a different time zone setting and it would provide that time zone's date/time. Hmmm... If you use a default value say of Now() on a column in a back-end database on the network, does Access use that network computer's clock? Or the front-end computer's clock? I presume the front-end computer's. For anything where it is critical to know the correct date/time, you need to use a database system that will use your server's clock and that will set the values by that clock regardless of how or from where the record is being created. And here is another issue when the correct date/time of creation is critical. It has to be set up so that that date/time can never be changed once it has been set. Things to think about, Clifford Bass David W. Fenton wrote: >> They each demostrate how to capture the DOC (Date of Creation) >> and >> the DOLE (Date of Last Edit) for each record. > >Date of Creation requires only a default value, no? > -- Message posted via AccessMonster.com http://www.accessmonster.com/Uwe/Forums.aspx/access-tablesdbdesign/200912/1
From: Al Campagna on 29 Dec 2009 09:05 Good point/s Clifford... Al Campagna "Clifford Bass via AccessMonster.com" <u48370(a)uwe> wrote in message news:a148c2c00e97c(a)uwe... > Hi, > > I find setting the default values for date/time fields in Access to > Date > (), Now() or Time() to be highly inaccurate because the value is set when > the > new row is displayed, not when data is initially being entered and not > when > it is actually saved. So if I go to a new record on 12/28/2009 at 11:50 > pm, > but do not actually start entering anything until 12/29/2009 at 12:15 am > and > do not actually save it until 12/29/2009 at 12:45 am, it will save with a > creation date of 12/28/2009 and a creation time of 11:50 pm. Which is > just > plain wrong. So the use of the Before Insert event to set it at the time > of > starting the record is a better solution. Likewise the use of the Before > Update event to set it at the time of saving. It would depend on what you > are defining as the creation date/time. The default values would be > useful > for situations where you are importing data; then you would not have to > set > the creation date/time explicitly. Of course, the whole issue can be > complicated further by an inaccurate computer clock. So I could be > entering > data on a computer with a different time zone setting and it would provide > that time zone's date/time. Hmmm... If you use a default value say of > Now() > on a column in a back-end database on the network, does Access use that > network computer's clock? Or the front-end computer's clock? I presume > the > front-end computer's. > > For anything where it is critical to know the correct date/time, you > need to use a database system that will use your server's clock and that > will > set the values by that clock regardless of how or from where the record is > being created. > > And here is another issue when the correct date/time of creation is > critical. It has to be set up so that that date/time can never be changed > once it has been set. > > Things to think about, > > Clifford Bass > > David W. Fenton wrote: >>> They each demostrate how to capture the DOC (Date of Creation) >>> and >>> the DOLE (Date of Last Edit) for each record. >> >>Date of Creation requires only a default value, no? >> > > -- > Message posted via AccessMonster.com > http://www.accessmonster.com/Uwe/Forums.aspx/access-tablesdbdesign/200912/1 >
From: David W. Fenton on 29 Dec 2009 11:52 "Al Campagna" <newsgroups(a)comcast.net> wrote in news:Ocy8w7AiKHA.5520(a)TK2MSFTNGP06.phx.gbl: > Regarding your comment about capturing Date instead of Now, > it's > usually preferable to capture Now... but just display Date format. It is perhaps preferable to *you* -- for me, I vastly prefer a date-only field. Where I need the time value, I use a separate column for the time part. > If an active and busy DB, which might have multiple edits > within a > day... it's > better to capture Now. So I think it's more a case of... why > guess whether Date is sufficient... just do Now, and you're always > OK. But it's much harder to query date fields with time parts, particularly if you are only ever displaying the date part. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 29 Dec 2009 11:53
"Clifford Bass via AccessMonster.com" <u48370(a)uwe> wrote in news:a148c2c00e97c(a)uwe: > I find setting the default values for date/time fields in Access > to Date (), Now() or Time() to be highly inaccurate because the > value is set when the new row is displayed, not when data is > initially being entered and not when it is actually saved. So if > I go to a new record on 12/28/2009 at 11:50 pm, but do not > actually start entering anything until 12/29/2009 at 12:15 am and > do not actually save it until 12/29/2009 at 12:45 am, it will save > with a creation date of 12/28/2009 and a creation time of 11:50 > pm. Which is just plain wrong. That's something I never considered. But I still prefer the default values in the table, nonetheless. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |