Refresh combobox

[Guest]

I have a database that is used to hire out equipment to employees. I have two
queries setup that show available equipment and unavailable equipment. When
hiring out equipment the user selects the equipment from a combobox. This
combobox is based on the available equipment query. This combobox is on a
continuous form such that many pieces of equipment can be hired out at once.
Once a piece of equipment has been hired out, I need the combobox to be
refreshed with the new available equipment, so avoiding double bocking). How
would I do this?

By the way, the combobox is on a subform.

Thanks

Dave

 

[Tom Ellison]

Dear David:

Refreshing combo boxes is a classic situation. There are several reasons
why this may be necessary:

1. As in your situation, saving changes in the current form may change what
should be shown in the combo box. I would recommend the AfterUpdate,
AfterDelConfirm, and AfterInsert events for this. Depending on the logic,
you man need it to react to updates, inserts, and deletions.

2. Another form or user action may change the data on which the combo or
list box bases its values. The GotFocus event will fire when the form is
re-entered afterward. Perform the same thing in this case.

3. If you have a multi-user system, so other user may do this as well.
There is no event for this! There are 2 suggestions I have for this:

a. Put a command button by the combo or list box so the user can choose
to refresh it. This is the simple, easy approach.

b. Refresh the list every time the control gets the focus. Also simple.

c. The above are not perfect. You can install a timer which checks for
changes. If there is a change, and the combo or list box has the focus, the
user needs to be informed that the range of selections has been changed, and
the list updated. This is a good solution for moderately active multi-user
situations. In a very active setup, with dozens of other users actively
changing the list, this would be constantly changing, so isn't a good
approach.

No matter which you choose, it would be advisable to check the selection
just before saving it, to make sure there was no last moment change in the
availability.

Programming this to "perfection" can be a pretty big deal. Likely, I would
set up a system where each item listed in the combo or list box has a set of
"alternatives" that can be chosen. For example, if you're checking out a
"lawn mower" and there are 5 of them, don't list all 5. Just list it1 time,
showing how many there are and how many are available. Don't show the
serial number of each one. Let the system assign that from all those
"available" when the "order" is "confirmed".

At the moment the form is "saved" find the serial number of an available
lawn mower (if any) and assign it them, to be shown in the form after the
"save" button is clicked. All this must be done with the table "locked" as
it is not a multi-user function to assign a lawn mower by serial number. Of
course, it is possible there won't be a lawn mower available when "save" is
clicked, even if there was one available when you started. You may want to
queue such requests and fill them as lawn mowers return, with automatic
email notification when it happens. You may even want to schedule the later
use of a lawn mower when it is expected back.

Wow! There's a lot to getting this right. I don't mean this to be a
discussion of the specifics of locking and serialization of critical steps,
but you'll need an understanding of that. Likely, this is overkill for what
you're building. If you don't need any of this, and don't build it into
your application, then it is still worth knowing about. When someone does
try to go heavy multi-user with your applicaiton and it fails, it will be
good to know why. Forewarned is forearmed!

I don't see this as a "computer caused problem." It is a real world problem
with an excellent computer solution.

If you had a counter with 5 clerks waiting on 30 people who each want one of
the 5 lawn mowers, how would you do it? You'd need a single clipboard with
5 papers, one for each lawn mower. Each clerk would have to wait to get the
clipboard to be able to find which, if any, lawnmower is available, and sign
up the person for that lawn mower. You can't have 3 people told they have
the same lawn mower converging on that mower and fighting over it. When you
assign a mower, it should be to only one person. Make sense? The computer
solution is rather similar!

Tom Ellison

 

[Guest]

Thanks for the reply. I've tried requerying the combobox in the after update
event of the appropriate fields but the combobox isn't updated. If I close
the form and reopen it the combobox contains the correct values.

The combobox is on a continuous form which is itself a subform. When a
return date is entered for a given piece of equipment (on the continuous
subform), this piece of equipment should be available as a selection in the
combobox. What should be requeried? The combobox? The main form? The subform?
The query that the combobox is based on? I can't seem to get it to update
without closing and reopening the form.

These are the queries that the combobox is based on:

First, work out the plant on hire:

SELECT DISTINCT PlantHireDetails.PlantID
FROM PlantHireDetails
WHERE PlantHireDetails.ReturnDate Is Null;

Then remove these from the available plant list to produce the query used on
the combobox:

SELECT DISTINCT Plant.PlantID, Plant.PlantName
FROM Plant LEFT JOIN PlantOnHire ON Plant.PlantID =
[PlantOnHire].PlantID
WHERE [PlantOnHire].PlantID IS NULL;

These queries produce the desired results.

Any ideas?

Thanks for the other information btw. My application is currently designed
for a single user but other applications I've designed may end up being
multi-user in the future.

Dave

 

[Tom Ellison]

Dear David:

I recommend you specifically requery the combo box itself.

Please create a temporary command button that does this. That way you know
the event to do this has fired. Does it update the list in the combo box
when done this way?

What you should do is confirm that the correct method is being used to make
the list change, and that the event you have shosen is firing at the
appropriate time. Having a separate command button tests the first.
Putting a break point in the code for the form's events will prove the
second.

Tom Ellison

Thanks for the reply. I've tried requerying the combobox in the after
update
event of the appropriate fields but the combobox isn't updated. If I close
the form and reopen it the combobox contains the correct values.

The combobox is on a continuous form which is itself a subform. When a
return date is entered for a given piece of equipment (on the continuous
subform), this piece of equipment should be available as a selection in
the
combobox. What should be requeried? The combobox? The main form? The
subform?
The query that the combobox is based on? I can't seem to get it to update
without closing and reopening the form.

These are the queries that the combobox is based on:

First, work out the plant on hire:

SELECT DISTINCT PlantHireDetails.PlantID
FROM PlantHireDetails
WHERE PlantHireDetails.ReturnDate Is Null;

Then remove these from the available plant list to produce the query used
on
the combobox:

SELECT DISTINCT Plant.PlantID, Plant.PlantName
FROM Plant LEFT JOIN PlantOnHire ON Plant.PlantID =
[PlantOnHire].PlantID
WHERE [PlantOnHire].PlantID IS NULL;

These queries produce the desired results.

Any ideas?

Thanks for the other information btw. My application is currently designed
for a single user but other applications I've designed may end up being
multi-user in the future.

Dave

Dear David:

Refreshing combo boxes is a classic situation. There are several reasons
why this may be necessary:

1. As in your situation, saving changes in the current form may change
what
should be shown in the combo box. I would recommend the AfterUpdate,
AfterDelConfirm, and AfterInsert events for this. Depending on the
logic,
you man need it to react to updates, inserts, and deletions.

2. Another form or user action may change the data on which the combo or
list box bases its values. The GotFocus event will fire when the form is
re-entered afterward. Perform the same thing in this case.

3. If you have a multi-user system, so other user may do this as well.
There is no event for this! There are 2 suggestions I have for this:

a. Put a command button by the combo or list box so the user can
choose
to refresh it. This is the simple, easy approach.

b. Refresh the list every time the control gets the focus. Also
simple.

c. The above are not perfect. You can install a timer which checks
for
changes. If there is a change, and the combo or list box has the focus,
the
user needs to be informed that the range of selections has been changed,
and
the list updated. This is a good solution for moderately active
multi-user
situations. In a very active setup, with dozens of other users actively
changing the list, this would be constantly changing, so isn't a good
approach.

No matter which you choose, it would be advisable to check the selection
just before saving it, to make sure there was no last moment change in
the
availability.

Programming this to "perfection" can be a pretty big deal. Likely, I
would
set up a system where each item listed in the combo or list box has a set
of
"alternatives" that can be chosen. For example, if you're checking out a
"lawn mower" and there are 5 of them, don't list all 5. Just list it1
time,
showing how many there are and how many are available. Don't show the
serial number of each one. Let the system assign that from all those
"available" when the "order" is "confirmed".

At the moment the form is "saved" find the serial number of an available
lawn mower (if any) and assign it them, to be shown in the form after the
"save" button is clicked. All this must be done with the table "locked"
as
it is not a multi-user function to assign a lawn mower by serial number.
Of
course, it is possible there won't be a lawn mower available when "save"
is
clicked, even if there was one available when you started. You may want
to
queue such requests and fill them as lawn mowers return, with automatic
email notification when it happens. You may even want to schedule the
later
use of a lawn mower when it is expected back.

Wow! There's a lot to getting this right. I don't mean this to be a
discussion of the specifics of locking and serialization of critical
steps,
but you'll need an understanding of that. Likely, this is overkill for
what
you're building. If you don't need any of this, and don't build it into
your application, then it is still worth knowing about. When someone
does
try to go heavy multi-user with your applicaiton and it fails, it will be
good to know why. Forewarned is forearmed!

I don't see this as a "computer caused problem." It is a real world
problem
with an excellent computer solution.

If you had a counter with 5 clerks waiting on 30 people who each want one
of
the 5 lawn mowers, how would you do it? You'd need a single clipboard
with
5 papers, one for each lawn mower. Each clerk would have to wait to get
the
clipboard to be able to find which, if any, lawnmower is available, and
sign
up the person for that lawn mower. You can't have 3 people told they
have
the same lawn mower converging on that mower and fighting over it. When
you
assign a mower, it should be to only one person. Make sense? The
computer
solution is rather similar!

Tom Ellison

 

[Guest]

OK, using the command button instead works, so now I just have to find the
correct event.

Thanks

Dave

Dear David:

I recommend you specifically requery the combo box itself.

Please create a temporary command button that does this. That way you know
the event to do this has fired. Does it update the list in the combo box
when done this way?

What you should do is confirm that the correct method is being used to make
the list change, and that the event you have shosen is firing at the
appropriate time. Having a separate command button tests the first.
Putting a break point in the code for the form's events will prove the
second.

Tom Ellison

Thanks for the reply. I've tried requerying the combobox in the after
update
event of the appropriate fields but the combobox isn't updated. If I close
the form and reopen it the combobox contains the correct values.

The combobox is on a continuous form which is itself a subform. When a
return date is entered for a given piece of equipment (on the continuous
subform), this piece of equipment should be available as a selection in
the
combobox. What should be requeried? The combobox? The main form? The
subform?
The query that the combobox is based on? I can't seem to get it to update
without closing and reopening the form.

These are the queries that the combobox is based on:

First, work out the plant on hire:

SELECT DISTINCT PlantHireDetails.PlantID
FROM PlantHireDetails
WHERE PlantHireDetails.ReturnDate Is Null;

Then remove these from the available plant list to produce the query used
on
the combobox:

SELECT DISTINCT Plant.PlantID, Plant.PlantName
FROM Plant LEFT JOIN PlantOnHire ON Plant.PlantID =
[PlantOnHire].PlantID
WHERE [PlantOnHire].PlantID IS NULL;

These queries produce the desired results.

Any ideas?

Thanks for the other information btw. My application is currently designed
for a single user but other applications I've designed may end up being
multi-user in the future.

Dave

Dear David:

Refreshing combo boxes is a classic situation. There are several reasons
why this may be necessary:

1. As in your situation, saving changes in the current form may change
what
should be shown in the combo box. I would recommend the AfterUpdate,
AfterDelConfirm, and AfterInsert events for this. Depending on the
logic,
you man need it to react to updates, inserts, and deletions.

2. Another form or user action may change the data on which the combo or
list box bases its values. The GotFocus event will fire when the form is
re-entered afterward. Perform the same thing in this case.

3. If you have a multi-user system, so other user may do this as well.
There is no event for this! There are 2 suggestions I have for this:

a. Put a command button by the combo or list box so the user can
choose
to refresh it. This is the simple, easy approach.

b. Refresh the list every time the control gets the focus. Also
simple.

c. The above are not perfect. You can install a timer which checks
for
changes. If there is a change, and the combo or list box has the focus,
the
user needs to be informed that the range of selections has been changed,
and
the list updated. This is a good solution for moderately active
multi-user
situations. In a very active setup, with dozens of other users actively
changing the list, this would be constantly changing, so isn't a good
approach.

No matter which you choose, it would be advisable to check the selection
just before saving it, to make sure there was no last moment change in
the
availability.

Programming this to "perfection" can be a pretty big deal. Likely, I
would
set up a system where each item listed in the combo or list box has a set
of
"alternatives" that can be chosen. For example, if you're checking out a
"lawn mower" and there are 5 of them, don't list all 5. Just list it1
time,
showing how many there are and how many are available. Don't show the
serial number of each one. Let the system assign that from all those
"available" when the "order" is "confirmed".

At the moment the form is "saved" find the serial number of an available
lawn mower (if any) and assign it them, to be shown in the form after the
"save" button is clicked. All this must be done with the table "locked"
as
it is not a multi-user function to assign a lawn mower by serial number.
Of
course, it is possible there won't be a lawn mower available when "save"
is
clicked, even if there was one available when you started. You may want
to
queue such requests and fill them as lawn mowers return, with automatic
email notification when it happens. You may even want to schedule the
later
use of a lawn mower when it is expected back.

Wow! There's a lot to getting this right. I don't mean this to be a
discussion of the specifics of locking and serialization of critical
steps,
but you'll need an understanding of that. Likely, this is overkill for
what
you're building. If you don't need any of this, and don't build it into
your application, then it is still worth knowing about. When someone
does
try to go heavy multi-user with your applicaiton and it fails, it will be
good to know why. Forewarned is forearmed!

I don't see this as a "computer caused problem." It is a real world
problem
with an excellent computer solution.

If you had a counter with 5 clerks waiting on 30 people who each want one
of
the 5 lawn mowers, how would you do it? You'd need a single clipboard
with
5 papers, one for each lawn mower. Each clerk would have to wait to get
the
clipboard to be able to find which, if any, lawnmower is available, and
sign
up the person for that lawn mower. You can't have 3 people told they
have
the same lawn mower converging on that mower and fighting over it. When
you
assign a mower, it should be to only one person. Make sense? The
computer
solution is rather similar!

Tom Ellison


I have a database that is used to hire out equipment to employees. I
have
two
queries setup that show available equipment and unavailable equipment.
When
hiring out equipment the user selects the equipment from a combobox.
This
combobox is based on the available equipment query. This combobox is on
a
continuous form such that many pieces of equipment can be hired out at
once.
Once a piece of equipment has been hired out, I need the combobox to be
refreshed with the new available equipment, so avoiding double
bocking).
How
would I do this?

By the way, the combobox is on a subform.

Thanks

Dave

 

[Tom Ellison]

Dear David:

The number one technique in debugging is: Divide and Conquer.

So, how about AfterUpdate for the event?

Tom Ellison

OK, using the command button instead works, so now I just have to find the
correct event.

Thanks

Dave

Dear David:

I recommend you specifically requery the combo box itself.

Please create a temporary command button that does this. That way you
know
the event to do this has fired. Does it update the list in the combo
box
when done this way?

What you should do is confirm that the correct method is being used to
make
the list change, and that the event you have shosen is firing at the
appropriate time. Having a separate command button tests the first.
Putting a break point in the code for the form's events will prove the
second.

Tom Ellison

Thanks for the reply. I've tried requerying the combobox in the after
update
event of the appropriate fields but the combobox isn't updated. If I
close
the form and reopen it the combobox contains the correct values.

The combobox is on a continuous form which is itself a subform. When a
return date is entered for a given piece of equipment (on the
continuous
subform), this piece of equipment should be available as a selection in
the
combobox. What should be requeried? The combobox? The main form? The
subform?
The query that the combobox is based on? I can't seem to get it to
update
without closing and reopening the form.

These are the queries that the combobox is based on:

First, work out the plant on hire:

SELECT DISTINCT PlantHireDetails.PlantID
FROM PlantHireDetails
WHERE PlantHireDetails.ReturnDate Is Null;

Then remove these from the available plant list to produce the query
used
on
the combobox:

SELECT DISTINCT Plant.PlantID, Plant.PlantName
FROM Plant LEFT JOIN PlantOnHire ON Plant.PlantID =
[PlantOnHire].PlantID
WHERE [PlantOnHire].PlantID IS NULL;

These queries produce the desired results.

Any ideas?

Thanks for the other information btw. My application is currently
designed
for a single user but other applications I've designed may end up being
multi-user in the future.

Dave


:

Dear David:

Refreshing combo boxes is a classic situation. There are several
reasons
why this may be necessary:

1. As in your situation, saving changes in the current form may
change
what
should be shown in the combo box. I would recommend the AfterUpdate,
AfterDelConfirm, and AfterInsert events for this. Depending on the
logic,
you man need it to react to updates, inserts, and deletions.

2. Another form or user action may change the data on which the combo
or
list box bases its values. The GotFocus event will fire when the form
is
re-entered afterward. Perform the same thing in this case.

3. If you have a multi-user system, so other user may do this as
well.
There is no event for this! There are 2 suggestions I have for this:

a. Put a command button by the combo or list box so the user can
choose
to refresh it. This is the simple, easy approach.

b. Refresh the list every time the control gets the focus. Also
simple.

c. The above are not perfect. You can install a timer which checks
for
changes. If there is a change, and the combo or list box has the
focus,
the
user needs to be informed that the range of selections has been
changed,
and
the list updated. This is a good solution for moderately active
multi-user
situations. In a very active setup, with dozens of other users
actively
changing the list, this would be constantly changing, so isn't a good
approach.

No matter which you choose, it would be advisable to check the
selection
just before saving it, to make sure there was no last moment change in
the
availability.

Programming this to "perfection" can be a pretty big deal. Likely, I
would
set up a system where each item listed in the combo or list box has a
set
of
"alternatives" that can be chosen. For example, if you're checking
out a
"lawn mower" and there are 5 of them, don't list all 5. Just list it1
time,
showing how many there are and how many are available. Don't show the
serial number of each one. Let the system assign that from all those
"available" when the "order" is "confirmed".

At the moment the form is "saved" find the serial number of an
available
lawn mower (if any) and assign it them, to be shown in the form after
the
"save" button is clicked. All this must be done with the table
"locked"
as
it is not a multi-user function to assign a lawn mower by serial
number.
Of
course, it is possible there won't be a lawn mower available when
"save"
is
clicked, even if there was one available when you started. You may
want
to
queue such requests and fill them as lawn mowers return, with
automatic
email notification when it happens. You may even want to schedule the
later
use of a lawn mower when it is expected back.

Wow! There's a lot to getting this right. I don't mean this to be a
discussion of the specifics of locking and serialization of critical
steps,
but you'll need an understanding of that. Likely, this is overkill
for
what
you're building. If you don't need any of this, and don't build it
into
your application, then it is still worth knowing about. When someone
does
try to go heavy multi-user with your applicaiton and it fails, it will
be
good to know why. Forewarned is forearmed!

I don't see this as a "computer caused problem." It is a real world
problem
with an excellent computer solution.

If you had a counter with 5 clerks waiting on 30 people who each want
one
of
the 5 lawn mowers, how would you do it? You'd need a single clipboard
with
5 papers, one for each lawn mower. Each clerk would have to wait to
get
the
clipboard to be able to find which, if any, lawnmower is available,
and
sign
up the person for that lawn mower. You can't have 3 people told they
have
the same lawn mower converging on that mower and fighting over it.
When
you
assign a mower, it should be to only one person. Make sense? The
computer
solution is rather similar!

Tom Ellison


I have a database that is used to hire out equipment to employees. I
have
two
queries setup that show available equipment and unavailable
equipment.
When
hiring out equipment the user selects the equipment from a combobox.
This
combobox is based on the available equipment query. This combobox is
on
a
continuous form such that many pieces of equipment can be hired out
at
once.
Once a piece of equipment has been hired out, I need the combobox to
be
refreshed with the new available equipment, so avoiding double
bocking).
How
would I do this?

By the way, the combobox is on a subform.

Thanks

Dave

 

[Guest]

I had tried the AfterUpdate event for the individual textbox that gets
updated but that didn't work. Using the AfterUpdate, AfterInsert and
AfterDelConfirm events of the whole subform seemed to do the trick.

Thanks for your help,

David

Dear David:

The number one technique in debugging is: Divide and Conquer.

So, how about AfterUpdate for the event?

Tom Ellison

OK, using the command button instead works, so now I just have to find the
correct event.

Thanks

Dave

Dear David:

I recommend you specifically requery the combo box itself.

Please create a temporary command button that does this. That way you
know
the event to do this has fired. Does it update the list in the combo
box
when done this way?

What you should do is confirm that the correct method is being used to
make
the list change, and that the event you have shosen is firing at the
appropriate time. Having a separate command button tests the first.
Putting a break point in the code for the form's events will prove the
second.

Tom Ellison


Thanks for the reply. I've tried requerying the combobox in the after
update
event of the appropriate fields but the combobox isn't updated. If I
close
the form and reopen it the combobox contains the correct values.

The combobox is on a continuous form which is itself a subform. When a
return date is entered for a given piece of equipment (on the
continuous
subform), this piece of equipment should be available as a selection in
the
combobox. What should be requeried? The combobox? The main form? The
subform?
The query that the combobox is based on? I can't seem to get it to
update
without closing and reopening the form.

These are the queries that the combobox is based on:

First, work out the plant on hire:

SELECT DISTINCT PlantHireDetails.PlantID
FROM PlantHireDetails
WHERE PlantHireDetails.ReturnDate Is Null;

Then remove these from the available plant list to produce the query
used
on
the combobox:

SELECT DISTINCT Plant.PlantID, Plant.PlantName
FROM Plant LEFT JOIN PlantOnHire ON Plant.PlantID =
[PlantOnHire].PlantID
WHERE [PlantOnHire].PlantID IS NULL;

These queries produce the desired results.

Any ideas?

Thanks for the other information btw. My application is currently
designed
for a single user but other applications I've designed may end up being
multi-user in the future.

Dave


:

Dear David:

Refreshing combo boxes is a classic situation. There are several
reasons
why this may be necessary:

1. As in your situation, saving changes in the current form may
change
what
should be shown in the combo box. I would recommend the AfterUpdate,
AfterDelConfirm, and AfterInsert events for this. Depending on the
logic,
you man need it to react to updates, inserts, and deletions.

2. Another form or user action may change the data on which the combo
or
list box bases its values. The GotFocus event will fire when the form
is
re-entered afterward. Perform the same thing in this case.

3. If you have a multi-user system, so other user may do this as
well.
There is no event for this! There are 2 suggestions I have for this:

a. Put a command button by the combo or list box so the user can
choose
to refresh it. This is the simple, easy approach.

b. Refresh the list every time the control gets the focus. Also
simple.

c. The above are not perfect. You can install a timer which checks
for
changes. If there is a change, and the combo or list box has the
focus,
the
user needs to be informed that the range of selections has been
changed,
and
the list updated. This is a good solution for moderately active
multi-user
situations. In a very active setup, with dozens of other users
actively
changing the list, this would be constantly changing, so isn't a good
approach.

No matter which you choose, it would be advisable to check the
selection
just before saving it, to make sure there was no last moment change in
the
availability.

Programming this to "perfection" can be a pretty big deal. Likely, I
would
set up a system where each item listed in the combo or list box has a
set
of
"alternatives" that can be chosen. For example, if you're checking
out a
"lawn mower" and there are 5 of them, don't list all 5. Just list it1
time,
showing how many there are and how many are available. Don't show the
serial number of each one. Let the system assign that from all those
"available" when the "order" is "confirmed".

At the moment the form is "saved" find the serial number of an
available
lawn mower (if any) and assign it them, to be shown in the form after
the
"save" button is clicked. All this must be done with the table
"locked"
as
it is not a multi-user function to assign a lawn mower by serial
number.
Of
course, it is possible there won't be a lawn mower available when
"save"
is
clicked, even if there was one available when you started. You may
want
to
queue such requests and fill them as lawn mowers return, with
automatic
email notification when it happens. You may even want to schedule the
later
use of a lawn mower when it is expected back.

Wow! There's a lot to getting this right. I don't mean this to be a
discussion of the specifics of locking and serialization of critical
steps,
but you'll need an understanding of that. Likely, this is overkill
for
what
you're building. If you don't need any of this, and don't build it
into
your application, then it is still worth knowing about. When someone
does
try to go heavy multi-user with your applicaiton and it fails, it will
be
good to know why. Forewarned is forearmed!

I don't see this as a "computer caused problem." It is a real world
problem
with an excellent computer solution.

If you had a counter with 5 clerks waiting on 30 people who each want
one
of
the 5 lawn mowers, how would you do it? You'd need a single clipboard
with
5 papers, one for each lawn mower. Each clerk would have to wait to
get
the
clipboard to be able to find which, if any, lawnmower is available,
and
sign
up the person for that lawn mower. You can't have 3 people told they
have
the same lawn mower converging on that mower and fighting over it.
When
you
assign a mower, it should be to only one person. Make sense? The
computer
solution is rather similar!

Tom Ellison


I have a database that is used to hire out equipment to employees. I
have
two
queries setup that show available equipment and unavailable
equipment.
When
hiring out equipment the user selects the equipment from a combobox.
This
combobox is based on the available equipment query. This combobox is
on
a
continuous form such that many pieces of equipment can be hired out
at
once.
Once a piece of equipment has been hired out, I need the combobox to
be
refreshed with the new available equipment, so avoiding double
bocking).
How
would I do this?

By the way, the combobox is on a subform.

Thanks

Dave

 

[Guest]

Tom,
I have a similar problem in that I need to refresh a combo-box on a subform
at the next record change. I have 3 combo boxes that require a security code
number prior to issuance of an extension date. What is happening is when the
next record of the subform is selected the combo boxes are holding the
previous value. When the combo box is first entered a msgbox asks for the
proper code number, if verified it drops down and displays the name of the
individual that code was assigned to. The user selects the name and proceeds.
Problem is the next record still has the previous name. I have tried several
events to get this solved.

Might you have a suggestion?

thanks

gavin hill

 

[Tom Ellison]

Dear Gavin:

Without seeing everything you have, I suspect the Current event is what you
need.

Rather than having the combo box open a parameter dialog, is it possible the
"code number" needed is somewhere on the form or in the RecordSource for the
form. If not, could it be easily added? Changing this query to reference a
control on the form, which you could add as "not visible" if you do not
already have it, would automate this. Requiring a user to type in a value
for "code number" and to do so without ever making an error is probably not
a superior design.

Tom Ellison