Up to date data

D

Derek Brown

Hi all

As advised by this newgroup, to keep current information on my forms
ComboBoxes subforms etc right up to date, I have used

Public Sub UpDateAll()
DoCmd.RunCommand acCmdSaveRecord
DBEngine.Idle dbRefreshCache
DoEvents
Forms![SchoolsForm]![Combo101].Requery
Forms![SchoolsForm]!Combo169.Requery
Forms![SchoolsForm]![Combo80].Requery
Forms![SchoolsForm]![Combo182].Requery
Forms![SchoolsForm]![Combo90].Requery
Forms![SchoolsForm]![Combo194].Requery
Forms![SchoolsForm]![Combo190].Requery
Forms![SchoolsForm]![Combo227].Requery
Forms![SchoolsForm]![Combo86].Requery
Forms![SchoolsForm]![Combo82].Requery
End Sub

At the beginning of each data changeable controls after update property I
entre "UpDateAll"

Is there not an property on the whole form that I can entre "UpDateAll" so
that when any change to data takes place the whole form can be updated? It
seems I am making a lot of work for something I feel instintively that
Access should do with ease.
 
D

Dirk Goldgar

Derek Brown said:
Hi all

As advised by this newgroup, to keep current information on my forms
ComboBoxes subforms etc right up to date, I have used

Public Sub UpDateAll()
DoCmd.RunCommand acCmdSaveRecord
DBEngine.Idle dbRefreshCache
DoEvents
Forms![SchoolsForm]![Combo101].Requery
Forms![SchoolsForm]!Combo169.Requery
Forms![SchoolsForm]![Combo80].Requery
Forms![SchoolsForm]![Combo182].Requery
Forms![SchoolsForm]![Combo90].Requery
Forms![SchoolsForm]![Combo194].Requery
Forms![SchoolsForm]![Combo190].Requery
Forms![SchoolsForm]![Combo227].Requery
Forms![SchoolsForm]![Combo86].Requery
Forms![SchoolsForm]![Combo82].Requery
End Sub

At the beginning of each data changeable controls after update
property I entre "UpDateAll"

Is there not an property on the whole form that I can entre
"UpDateAll" so that when any change to data takes place the whole
form can be updated? It seems I am making a lot of work for something
I feel instintively that Access should do with ease.

What level of "up-to-date-ness" do you really need? The above code,
called from every control's AfterUpdate event, is going to force the
current record to be saved immediately whenever the user changes any
control -- event if the user might have changed his mind afterward and
not wanted to save the record. For most purposes, I would have thought
it sufficient -- and less cumbersome -- to requery the combo boxes only
in the *form's* AfterUpdate event, since you know at that point that the
modified record was saved.

Are you concerned about data having been added by other users?
 
D

Derek Brown

Hi Dirk

I am producing a contact database that amongst the general stuff also stores
appointments. For me its important that when a new appointment is made that
it be immediately shown on many of the combo boxes that show the
appointments in many ways such as sorted by date and time, by post code, by
week, by month etc. One of the combo boxes lists the new contacts to be
called. When there is no reply by phone it automatically adds 10 minutes to
the recall time and if the combo is requeried it takes it off the list for
the next 10 minutes, so the telesales girl can just keep choosing calls from
the top of the list without worrying about forgetting to call back. So you
can see imediate and right up to date is what is needed.

Many thanks

Dirk Goldgar said:
Derek Brown said:
Hi all

As advised by this newgroup, to keep current information on my forms
ComboBoxes subforms etc right up to date, I have used

Public Sub UpDateAll()
DoCmd.RunCommand acCmdSaveRecord
DBEngine.Idle dbRefreshCache
DoEvents
Forms![SchoolsForm]![Combo101].Requery
Forms![SchoolsForm]!Combo169.Requery
Forms![SchoolsForm]![Combo80].Requery
Forms![SchoolsForm]![Combo182].Requery
Forms![SchoolsForm]![Combo90].Requery
Forms![SchoolsForm]![Combo194].Requery
Forms![SchoolsForm]![Combo190].Requery
Forms![SchoolsForm]![Combo227].Requery
Forms![SchoolsForm]![Combo86].Requery
Forms![SchoolsForm]![Combo82].Requery
End Sub

At the beginning of each data changeable controls after update
property I entre "UpDateAll"

Is there not an property on the whole form that I can entre
"UpDateAll" so that when any change to data takes place the whole
form can be updated? It seems I am making a lot of work for something
I feel instintively that Access should do with ease.

What level of "up-to-date-ness" do you really need? The above code,
called from every control's AfterUpdate event, is going to force the
current record to be saved immediately whenever the user changes any
control -- event if the user might have changed his mind afterward and
not wanted to save the record. For most purposes, I would have thought
it sufficient -- and less cumbersome -- to requery the combo boxes only
in the *form's* AfterUpdate event, since you know at that point that the
modified record was saved.

Are you concerned about data having been added by other users?

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)
 
D

Dirk Goldgar

Hmm. Without seeing how your form and tables are structured, I can't
suggest much beyond the fact that there must be some event that
constitutes "making an appointment", so if combo boxes only need to be
requeried when an appointment is made, that event would be the one to
use. If the form is based on the table of appointments, so that the
form's AfterUpdate event is triggered when an appointment is made, then
it seems to me that would be the event to use, and no event before that
would be meaningful. You might, though, have cause to force an
appointment-in-the-making to be saved in various other events; possibly
multiple control events, I really can't say.

The business involving the "contacts-to-be-called" combo box seems to be
a separate but similar problem -- there has to be a data event that
reflects the fact that a call was made, and the disposition of the call.
The combo box's rowsource query would want to be defined such that the
list of calls to make (in the combo box) reflects the disposition of
previous calls -- "call back after x o'clock", "don't call back",
whatever. So the update of whatever table stores the disposition of
each call would be the appropriate event in which to requery the combo
box.

I'm afraid that may not be much help to you, but really without seeing
the whole database and how it's supposed to work - which is really
beyond the limits of newsgroup support -- I can't think of any better
advice to give..

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)


Derek Brown said:
Hi Dirk

I am producing a contact database that amongst the general stuff also
stores appointments. For me its important that when a new appointment
is made that it be immediately shown on many of the combo boxes that
show the appointments in many ways such as sorted by date and time,
by post code, by week, by month etc. One of the combo boxes lists
the new contacts to be called. When there is no reply by phone it
automatically adds 10 minutes to the recall time and if the combo is
requeried it takes it off the list for the next 10 minutes, so the
telesales girl can just keep choosing calls from the top of the list
without worrying about forgetting to call back. So you can see
imediate and right up to date is what is needed.

Many thanks

Dirk Goldgar said:
Derek Brown said:
Hi all

As advised by this newgroup, to keep current information on my forms
ComboBoxes subforms etc right up to date, I have used

Public Sub UpDateAll()
DoCmd.RunCommand acCmdSaveRecord
DBEngine.Idle dbRefreshCache
DoEvents
Forms![SchoolsForm]![Combo101].Requery
Forms![SchoolsForm]!Combo169.Requery
Forms![SchoolsForm]![Combo80].Requery
Forms![SchoolsForm]![Combo182].Requery
Forms![SchoolsForm]![Combo90].Requery
Forms![SchoolsForm]![Combo194].Requery
Forms![SchoolsForm]![Combo190].Requery
Forms![SchoolsForm]![Combo227].Requery
Forms![SchoolsForm]![Combo86].Requery
Forms![SchoolsForm]![Combo82].Requery
End Sub

At the beginning of each data changeable controls after update
property I entre "UpDateAll"

Is there not an property on the whole form that I can entre
"UpDateAll" so that when any change to data takes place the whole
form can be updated? It seems I am making a lot of work for
something I feel instintively that Access should do with ease.

What level of "up-to-date-ness" do you really need? The above code,
called from every control's AfterUpdate event, is going to force the
current record to be saved immediately whenever the user changes any
control -- event if the user might have changed his mind afterward
and not wanted to save the record. For most purposes, I would have
thought it sufficient -- and less cumbersome -- to requery the combo
boxes only in the *form's* AfterUpdate event, since you know at that
point that the modified record was saved.

Are you concerned about data having been added by other users?
 
D

Derek Brown

Thanks Dirk

My main concern was that I was missing something obvious. From what you say
it looks OK. We are a little unusual at my company. We are not brilliant at
writing code (that doesn't help us) most of our effort goes into making
stuff that is idiot proof and when a new operator gets hold of software they
simply cannot understand why when some information on a form is changed that
it doesn't appear updated immediately elsewhere. We also hate having to open
a new form for every slight change in data type so we cram a lot on one form
and label it as plainly as possible. So whereas it would be the norm to
split thing up and have many simpler forms, fitting more stuff onto a single
form does cause us problems sometimes. So thank you for your input its most
appreciated.

Dirk Goldgar said:
Hmm. Without seeing how your form and tables are structured, I can't
suggest much beyond the fact that there must be some event that
constitutes "making an appointment", so if combo boxes only need to be
requeried when an appointment is made, that event would be the one to
use. If the form is based on the table of appointments, so that the
form's AfterUpdate event is triggered when an appointment is made, then
it seems to me that would be the event to use, and no event before that
would be meaningful. You might, though, have cause to force an
appointment-in-the-making to be saved in various other events; possibly
multiple control events, I really can't say.

The business involving the "contacts-to-be-called" combo box seems to be
a separate but similar problem -- there has to be a data event that
reflects the fact that a call was made, and the disposition of the call.
The combo box's rowsource query would want to be defined such that the
list of calls to make (in the combo box) reflects the disposition of
previous calls -- "call back after x o'clock", "don't call back",
whatever. So the update of whatever table stores the disposition of
each call would be the appropriate event in which to requery the combo
box.

I'm afraid that may not be much help to you, but really without seeing
the whole database and how it's supposed to work - which is really
beyond the limits of newsgroup support -- I can't think of any better
advice to give..

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)


Derek Brown said:
Hi Dirk

I am producing a contact database that amongst the general stuff also
stores appointments. For me its important that when a new appointment
is made that it be immediately shown on many of the combo boxes that
show the appointments in many ways such as sorted by date and time,
by post code, by week, by month etc. One of the combo boxes lists
the new contacts to be called. When there is no reply by phone it
automatically adds 10 minutes to the recall time and if the combo is
requeried it takes it off the list for the next 10 minutes, so the
telesales girl can just keep choosing calls from the top of the list
without worrying about forgetting to call back. So you can see
imediate and right up to date is what is needed.

Many thanks

Dirk Goldgar said:
Hi all

As advised by this newgroup, to keep current information on my forms
ComboBoxes subforms etc right up to date, I have used

Public Sub UpDateAll()
DoCmd.RunCommand acCmdSaveRecord
DBEngine.Idle dbRefreshCache
DoEvents
Forms![SchoolsForm]![Combo101].Requery
Forms![SchoolsForm]!Combo169.Requery
Forms![SchoolsForm]![Combo80].Requery
Forms![SchoolsForm]![Combo182].Requery
Forms![SchoolsForm]![Combo90].Requery
Forms![SchoolsForm]![Combo194].Requery
Forms![SchoolsForm]![Combo190].Requery
Forms![SchoolsForm]![Combo227].Requery
Forms![SchoolsForm]![Combo86].Requery
Forms![SchoolsForm]![Combo82].Requery
End Sub

At the beginning of each data changeable controls after update
property I entre "UpDateAll"

Is there not an property on the whole form that I can entre
"UpDateAll" so that when any change to data takes place the whole
form can be updated? It seems I am making a lot of work for
something I feel instintively that Access should do with ease.

What level of "up-to-date-ness" do you really need? The above code,
called from every control's AfterUpdate event, is going to force the
current record to be saved immediately whenever the user changes any
control -- event if the user might have changed his mind afterward
and not wanted to save the record. For most purposes, I would have
thought it sufficient -- and less cumbersome -- to requery the combo
boxes only in the *form's* AfterUpdate event, since you know at that
point that the modified record was saved.

Are you concerned about data having been added by other users?
 
D

Derek Brown

Hi Dirk

I did send a lengthy explanation of our needs to this group but it has not
appeared so my appologies for not apearing to respond. Its basically that
when a user enters any data, they, naturally (we beleive) want to see the
change imediately. If you are using the database as a tool for contacting
customers we want the database to remove contacts from the list for the time
period selected (5 minutes for example) if no contact with the customer can
be made. This enables the user to simply keep calling customers from the top
of the combo box list. The customer then appears at the top of the list in 5
minutes time. To do this we need the customer that has not reponded to be
removed temporarily but immediately from the combo box.

Thanks.


Dirk Goldgar said:
Hmm. Without seeing how your form and tables are structured, I can't
suggest much beyond the fact that there must be some event that
constitutes "making an appointment", so if combo boxes only need to be
requeried when an appointment is made, that event would be the one to
use. If the form is based on the table of appointments, so that the
form's AfterUpdate event is triggered when an appointment is made, then
it seems to me that would be the event to use, and no event before that
would be meaningful. You might, though, have cause to force an
appointment-in-the-making to be saved in various other events; possibly
multiple control events, I really can't say.

The business involving the "contacts-to-be-called" combo box seems to be
a separate but similar problem -- there has to be a data event that
reflects the fact that a call was made, and the disposition of the call.
The combo box's rowsource query would want to be defined such that the
list of calls to make (in the combo box) reflects the disposition of
previous calls -- "call back after x o'clock", "don't call back",
whatever. So the update of whatever table stores the disposition of
each call would be the appropriate event in which to requery the combo
box.

I'm afraid that may not be much help to you, but really without seeing
the whole database and how it's supposed to work - which is really
beyond the limits of newsgroup support -- I can't think of any better
advice to give..

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)


Derek Brown said:
Hi Dirk

I am producing a contact database that amongst the general stuff also
stores appointments. For me its important that when a new appointment
is made that it be immediately shown on many of the combo boxes that
show the appointments in many ways such as sorted by date and time,
by post code, by week, by month etc. One of the combo boxes lists
the new contacts to be called. When there is no reply by phone it
automatically adds 10 minutes to the recall time and if the combo is
requeried it takes it off the list for the next 10 minutes, so the
telesales girl can just keep choosing calls from the top of the list
without worrying about forgetting to call back. So you can see
imediate and right up to date is what is needed.

Many thanks

Dirk Goldgar said:
Hi all

As advised by this newgroup, to keep current information on my forms
ComboBoxes subforms etc right up to date, I have used

Public Sub UpDateAll()
DoCmd.RunCommand acCmdSaveRecord
DBEngine.Idle dbRefreshCache
DoEvents
Forms![SchoolsForm]![Combo101].Requery
Forms![SchoolsForm]!Combo169.Requery
Forms![SchoolsForm]![Combo80].Requery
Forms![SchoolsForm]![Combo182].Requery
Forms![SchoolsForm]![Combo90].Requery
Forms![SchoolsForm]![Combo194].Requery
Forms![SchoolsForm]![Combo190].Requery
Forms![SchoolsForm]![Combo227].Requery
Forms![SchoolsForm]![Combo86].Requery
Forms![SchoolsForm]![Combo82].Requery
End Sub

At the beginning of each data changeable controls after update
property I entre "UpDateAll"

Is there not an property on the whole form that I can entre
"UpDateAll" so that when any change to data takes place the whole
form can be updated? It seems I am making a lot of work for
something I feel instintively that Access should do with ease.

What level of "up-to-date-ness" do you really need? The above code,
called from every control's AfterUpdate event, is going to force the
current record to be saved immediately whenever the user changes any
control -- event if the user might have changed his mind afterward
and not wanted to save the record. For most purposes, I would have
thought it sufficient -- and less cumbersome -- to requery the combo
boxes only in the *form's* AfterUpdate event, since you know at that
point that the modified record was saved.

Are you concerned about data having been added by other users?
 
D

Dirk Goldgar

Derek Brown said:
Hi Dirk

I did send a lengthy explanation of our needs to this group but it
has not appeared so my appologies for not apearing to respond. Its
basically that when a user enters any data, they, naturally (we
beleive) want to see the change imediately. If you are using the
database as a tool for contacting customers we want the database to
remove contacts from the list for the time period selected (5 minutes
for example) if no contact with the customer can be made. This
enables the user to simply keep calling customers from the top of the
combo box list. The customer then appears at the top of the list in 5
minutes time. To do this we need the customer that has not reponded
to be removed temporarily but immediately from the combo box.

Hi, Derek -

I'm not sure whether you've got this matter all under control at this
point or not. Let me know if you have any more questions.
 
Top