timer to update time field

[Josh]

Users input receipts on a form, which has a Date/Time field. The
Date/Time field has default value of Now when form loads. But, the
default time of the Date/Time stays at that same value, of course,
until the Form closes. Because the receipts cover several days or even
a week, and then user catches up all at once, I can't update the
Date/Time through code when they actually Post (add the record). The
user has to input the correct Date/Time of the receipt.

I'm getting problems in user clicking or tabbing into the Date/Time
field, and only putting the Date in, which makes the time 12:00. I
could probably solve that by putting in a mask or something, but then
I realized that I also have the problem of the same Time being put on
all Receipts, because of the Default value.

What I would like is; user can change Date, but Time is being
continually updated on its own. The reason for keeping control on
Time is because of some Printing that goes on, the Print code looks to
the Time. (print report of all receipts posted since such and such
Date/Time).

Any suggestions? I can separate the Date and Time fields into two
unbound fields on the form, and then put both into actual Date/Time
field, but don't have any idea how to continaully update Time field.

Thanks, Josh

 

[Josh]

Right after I posted this, I thought "jeez I'm making this harder than
I need to"...I guess I just need to have an unbound DATE field
(txtDATE) on form, user doens't even see TIME. User can then change
DATE as needed, when click POST to udd the record, insert "txtDATE &
Time()" into the Date/Time field.
Josh

 

[John W. Vinson]

Right after I posted this, I thought "jeez I'm making this harder than
I need to"...I guess I just need to have an unbound DATE field
(txtDATE) on form, user doens't even see TIME. User can then change
DATE as needed, when click POST to udd the record, insert "txtDATE &
Time()" into the Date/Time field.

This isn't making sense to me.

That would store a date some days past... and the current time. Thus if a sale
took place on December 18 at 11:30am, and the user entered it into the
database on January 2 at 4:30 pm, it would store an artificial time -
#12/18/2008 16:30:00#, which was neither the date/time of the sale nor the
date/time of the entry.

What is the purpose of this phony field value!?

 

[Josh]

This isn't making sense to me.

That would store a date some days past... and the current time. Thus if a sale
took place on December 18 at 11:30am, and the user entered it into the
database on January 2 at 4:30 pm, it would store an artificial time -
#12/18/2008 16:30:00#, which was neither the date/time of the sale nor the
date/time of the entry.

What is the purpose of this phony field value!?

It's an admitted kludge for the following purpose, to get a setpoint
for "print a summary of all activity since we last printed a summary".
And, to use Date/Time for Sorting, rather than an ID type field.

The TIME doesnt' really matter, other than for sorting purposes. Only
the Date really matters. We give receipts from third party pre-printed
forms. And post those receipts in order, but it might be days/weeks
later that they're posted. The TIME is artifical, but helps in
sorting. I tried using an autonumber field, but there are frequent
mistakes which have to be corrected, so therefore an autonumber field
doesn't work. As an aside, this was an import from a DOS program, and
the SEQ numbers in that program don't match the DATE field.

I know this doesn't make a lot of sense, I think I either need to
re-import the DOS program data, Sort by Date and then assign an
autonumber and use that autonumber for sorting, and think of a way to
prevent mistakes, or think of another way. I agree that is seems
unneccessarily convoluted. Part of the problem is that the reciepts
can stack up, and receipts 44-150 are input for 12/20/2008, then
realize, oh, here's receipts 40-43 than need to go in.

Josh

 

[John W. Vinson]

I agree that is seems
unneccessarily convoluted. Part of the problem is that the reciepts
can stack up, and receipts 44-150 are input for 12/20/2008, then
realize, oh, here's receipts 40-43 than need to go in.

That'll mess up your solution too, won't it?

I'd really use two fields, since the two chunks of information are used for
quite different purposes: storing a real, meaningful date, and storing an
arbitrary sequence number!

 

[Clifford Bass]

Hi Josh,

Or, alternatively, store a separate date-last-modified that is set in
the form's Before Update event.

Clifford Bass

 

[Clifford Bass]

Hi Josh,

Clarification: date and time-last-modified.

Clifford Bass

 

[Josh]

I do, although it is set on the "print summary of activity since
printed last summary" cmd button's on click event.

thanks, Josh

 

[Josh]

That'll mess up your solution too, won't it?

I'd really use two fields, since the two chunks of information are used for
quite different purposes: storing a real, meaningful date, and storing an
arbitrary sequence number!

I guess thats what I thought I was doing, using DATE as first sort,
and TIME as a second sort number.

I'll think on this some more, but thanks for the input, makes me think
outside the 'groove' I had made for myself on this.

Thanks, Josh

 

[Clifford Bass]

Hi Josh,

I mean that you store it in each record whenever each record is
added/modified. That in addition to storing the date/time summary last
printed. Then the value you store when you print the summary can be used to
filter all records modified/added since.

Clifford Bass