I need to set up two fields in a database.......

[MalTom]

1 which can be used to enter a date of a phone call and another that
automatically shows a date say 30days away for a recall. I will then run a
daily report showing the calls to make on that day. I can't remember the
expression required please help!!

 

[StrayBullet]

On your form, you can use
=Date()
as the default value of[txtCallReceived] and
=[txtCallReceived] + 30
as the default value of [txtRecall]
These will write the desired values to the fields and allow the default
values to be overridden if needed.

 

[MalTom]

Can you write the expression out as it should look - I have a mental block
tonght!!!!!

Thanks

On your form, you can use
=Date()
as the default value of[txtCallReceived] and
=[txtCallReceived] + 30
as the default value of [txtRecall]
These will write the desired values to the fields and allow the default
values to be overridden if needed.

1 which can be used to enter a date of a phone call and another that
automatically shows a date say 30days away for a recall. I will then run a
daily report showing the calls to make on that day. I can't remember the
expression required please help!!

 

[Jeff Boyce]

While is it possible to do, storing a calculated value is rarely a good
idea.

If you were going to be running a query anyway to see what calls are needed
on what day, do the calculation in THAT query!

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[StrayBullet via AccessMonster.com]

True... However, when dealing with this sort of situation, it's often
advantageous to save both values. Even though the preferred timeframe is 30
days (in this case), often customers will not want a callback until after a
different amount of time has passed (2 weeks, 6 months, 1 year) Storing the
values allows this to be accomodated.

 

[StrayBullet via AccessMonster.com]

What's above is pretty much it...

Can you write the expression out as it should look - I have a mental block
tonght!!!!!

Thanks

On your form, you can use
=Date()

[quoted text clipped - 8 lines]

 

[Jeff Boyce]

Ah! That's a piece of the requirements (store a varying number of callback
days) that wasn't in the original specs!

Still, as a general approach, your database would have stronger integrity
and less likelihood of inconsistent data if you store the calldate, and
store the "Call me back after 'nn' days", but NOT the calculated future
date. Again, doing the calculation ([CallDate] + [After nn days]) will give
you the future date, and will accommodate any changes (i.e., "corrections")
to either [CallDate] or [After nn days] values.

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[StrayBullet via AccessMonster.com]

Good point - except for having to explain to a phone operator why she needs
to figure out how many days until June 17th lol

Ah! That's a piece of the requirements (store a varying number of callback
days) that wasn't in the original specs!

Still, as a general approach, your database would have stronger integrity
and less likelihood of inconsistent data if you store the calldate, and
store the "Call me back after 'nn' days", but NOT the calculated future
date. Again, doing the calculation ([CallDate] + [After nn days]) will give
you the future date, and will accommodate any changes (i.e., "corrections")
to either [CallDate] or [After nn days] values.

Regards

Jeff Boyce
Microsoft Office/Access MVP

True... However, when dealing with this sort of situation, it's often
advantageous to save both values. Even though the preferred timeframe is

[quoted text clipped - 4 lines]

the
values allows this to be accomodated.

 

[Jeff Boyce]

Nah... I wouldn't put the operator through that. Access is smart enough to
be able to calculate how many days. I'd probably even include a calendar
that lets someone pick a date (?!?), but behind the curtain, I'd store the
number of days. I may be gun-shy, but I've seen too many situations in
which the date-in-the-future was stored, then either CallDate or
DateInTheFuture were modified, and there was no way (short of adding
additional functions/programming) to catch/fix the inconsistency.

Regards

Jeff Boyce
Microsoft Office/Access MVP

Good point - except for having to explain to a phone operator why she
needs
to figure out how many days until June 17th lol

Ah! That's a piece of the requirements (store a varying number of
callback
days) that wasn't in the original specs!

Still, as a general approach, your database would have stronger integrity
and less likelihood of inconsistent data if you store the calldate, and
store the "Call me back after 'nn' days", but NOT the calculated future
date. Again, doing the calculation ([CallDate] + [After nn days]) will
give
you the future date, and will accommodate any changes (i.e.,
"corrections")
to either [CallDate] or [After nn days] values.

Regards

Jeff Boyce
Microsoft Office/Access MVP

True... However, when dealing with this sort of situation, it's often
advantageous to save both values. Even though the preferred timeframe is

[quoted text clipped - 4 lines]

the
values allows this to be accomodated.

 

[StrayBullet via AccessMonster.com]

While I do like your idea (alot!), if editing the CallDate automatically
recalculates the RecallDate based on a saved number of days, the Recall will
not occur when intended. Unfortunately, this situation is one of those in
which one or more tradeoffs may be in order - dealing with humans on both
ends of a phoneline is one of the worst combinations to have to plan around.

Nah... I wouldn't put the operator through that. Access is smart enough to
be able to calculate how many days. I'd probably even include a calendar
that lets someone pick a date (?!?), but behind the curtain, I'd store the
number of days. I may be gun-shy, but I've seen too many situations in
which the date-in-the-future was stored, then either CallDate or
DateInTheFuture were modified, and there was no way (short of adding
additional functions/programming) to catch/fix the inconsistency.

Regards

Jeff Boyce
Microsoft Office/Access MVP

Good point - except for having to explain to a phone operator why she
needs

[quoted text clipped - 23 lines]

 

[Jeff Boyce]

Actually, short of inventing some synchronization code, I believe Access
doesn't have the kind of table triggers you'd need to get an automatic
recalc. I still think if working in Access, the best approach is to embed
the calculation in the query that looks for potential callbacks.

Regards

Jeff Boyce
Microsoft Office/Access MVP

While I do like your idea (alot!), if editing the CallDate automatically
recalculates the RecallDate based on a saved number of days, the Recall
will
not occur when intended. Unfortunately, this situation is one of those in
which one or more tradeoffs may be in order - dealing with humans on both
ends of a phoneline is one of the worst combinations to have to plan
around.

Nah... I wouldn't put the operator through that. Access is smart enough
to
be able to calculate how many days. I'd probably even include a calendar
that lets someone pick a date (?!?), but behind the curtain, I'd store the
number of days. I may be gun-shy, but I've seen too many situations in
which the date-in-the-future was stored, then either CallDate or
DateInTheFuture were modified, and there was no way (short of adding
additional functions/programming) to catch/fix the inconsistency.

Regards

Jeff Boyce
Microsoft Office/Access MVP

Good point - except for having to explain to a phone operator why she
needs

[quoted text clipped - 23 lines]

the
values allows this to be accomodated.

 

[StrayBullet via AccessMonster.com]

Of course silly! I wasn't implying that any of this would occur at the table
level... And you are correct, there is no provision for calculation at the
table level in Access. The recalculation I was referring to would occur on a
form, report, or simply in a query.

Actually, short of inventing some synchronization code, I believe Access
doesn't have the kind of table triggers you'd need to get an automatic
recalc. I still think if working in Access, the best approach is to embed
the calculation in the query that looks for potential callbacks.

Regards

Jeff Boyce
Microsoft Office/Access MVP

While I do like your idea (alot!), if editing the CallDate automatically
recalculates the RecallDate based on a saved number of days, the Recall

[quoted text clipped - 23 lines]