J
John W. Vinson
A Combo Box based on a table of cities will do so, yes.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
A Combo Box based on a table of cities will do so, yes.
G
Gina Whipp
Armen,
I guess I handle mine differently because the End User cannot add a City...
They have to get the *Admin* to add it. (I have a File Maintenance section
that on the *System Admin* can get to. This also prevents
changes/additions/deletions from other tables that have look-up values.) Of
course, I include a City, State and FIPS Code table in all my databases so
the odds of them typing a City I don't have is a zillion to one.
However, unless you have such a table probably better to do it your way!
--
Gina Whipp
2010 Microsoft MVP (Access)
"I feel I have been denied critical, need to know, information!" - Tremors
II
http://www.regina-whipp.com/index_files/TipList.htm
Yes. A combobox has a built-in ability to display the whole value of
the first match it finds, which makes data entry much quicker.
However, the way we do it just discourages typos, it doesn't *prevent*
them. If they type a new city name, we add it to the lookup table
automatically and silently. So it's possible to add a misspelled
city. It's just not that big of a deal to remove it later, and we
find that when a correctly spelled city is in there already, people
tend to just use it and not get creative with a new spelling.
You typically need some kind of add-on-the-fly because new cities will
need to be added all the time.
You could prompt the user in the Not In List event to see if they want
to add a new city, but we don't want to slow down the data entry
process. So we just add it in there without asking.
Armen Stein
Microsoft Access MVP
www.JStreetTech.com
I guess I handle mine differently because the End User cannot add a City...
They have to get the *Admin* to add it. (I have a File Maintenance section
that on the *System Admin* can get to. This also prevents
changes/additions/deletions from other tables that have look-up values.) Of
course, I include a City, State and FIPS Code table in all my databases so
the odds of them typing a City I don't have is a zillion to one.
However, unless you have such a table probably better to do it your way!
--
Gina Whipp
2010 Microsoft MVP (Access)
"I feel I have been denied critical, need to know, information!" - Tremors
II
http://www.regina-whipp.com/index_files/TipList.htm
That is what we are suggesting but with the table set up so they can't make
a typo.
Yes. A combobox has a built-in ability to display the whole value of
the first match it finds, which makes data entry much quicker.
However, the way we do it just discourages typos, it doesn't *prevent*
them. If they type a new city name, we add it to the lookup table
automatically and silently. So it's possible to add a misspelled
city. It's just not that big of a deal to remove it later, and we
find that when a correctly spelled city is in there already, people
tend to just use it and not get creative with a new spelling.
You typically need some kind of add-on-the-fly because new cities will
need to be added all the time.
You could prompt the user in the Not In List event to see if they want
to add a new city, but we don't want to slow down the data entry
process. So we just add it in there without asking.
Armen Stein
Microsoft Access MVP
www.JStreetTech.com
A
Armen Stein
I include a City, State and FIPS Code table in all my databases so
the odds of them typing a City I don't have is a zillion to one.
However, unless you have such a table probably better to do it your way!
We don't normally include such a table because we don't want our
client to need to keep it up to date, their addresses are usually
quite localized anyway, and we don't usually need 100% accuracy (no
bulk mail). So our method works fine in *most* cases. In other cases
we've gone the other direction and written interfaces to
address-scrubbing APIs, so I see your point!
Cheers,
Armen Stein
Microsoft Access MVP
www.JStreetTech.com
D
David W. Fenton
- we create tblCity
- we create relationships from any table with an address to
tblCity using CityName, without enforcing referential integrity.
- on our forms, the City combobox helps users remember the
spelling of the city and type it in faster.
- the City combobox traps for NotInList and silently adds a new
City on the fly.
- we build a simple admin screen to allow the user to delete
incorrect cities. They should also find and correct those cities
in the address tables.
I never bother with that. I just base the combo box on the unique
values for the data field it's bound to. This does require a hidden
field for saving the data before requerying the combo box, but it's
so much easier that mucking around with maintaining a lookup table.
D
David W. Fenton
You could prompt the user in the Not In List event to see if they
want to add a new city, but we don't want to slow down the data
entry process. So we just add it in there without asking.
I would say that there's little point in a combo box if you're not
going to inform the user that they've typed a value that's not in
the list. While you certainly get the value of Autocomplete in
nudging them in the direction of choosing something that already
exists (and also there's the problem of users not paying attention
and choosing the wrong autocompleted value, but there's nothing can
be done about that!), but I really think the user should be informed
that they've typed a value that's not in the list.
A
Armen Stein
I never bother with that. I just base the combo box on the unique
values for the data field it's bound to. This does require a hidden
field for saving the data before requerying the combo box, but it's
so much easier that mucking around with maintaining a lookup table.
Good point. We've done the unique values approach too, but you can
run into performance problems on large recordsets.
Armen Stein
Microsoft Access MVP
www.JStreetTech.com
D
David W. Fenton
Good point. We've done the unique values approach too, but you
can run into performance problems on large recordsets.
....in which case a combo box is likely not the correct interface
control (or you need to prefilter it, which means its recordsource
has to be a UNION with a SELECT statement returning the value for
the current record and it has to be requried on each row).
T
TGC
Hello again! Did you get a chance to review the questions from my 1/26 post
from this string?
Thanks again!
Ellen
from this string?
Thanks again!
Ellen
G
Gina Whipp
Ellen,
I guess you can't see my answer so I am reposting...
********
Okay... no worries about the all caps... I hate it also, looks like
yelling, but I get why you did it.
Right now, I just want to focus on the Bid Schedule so I can get that thru
my *thick* head and then I'll deal with the other questions/comments...
So, if I understand the below... The Bid Schedule is attached to the
Property and there will always be only one date in that field. If that is
true then it only needs to be in tblProperty. Having it in tblCompany
serves no purpose unless I missed something.
tblProperty
pBidSchedule
pCompanyID ---> tblCompanyContacts (ccCompanyID)
OR
tblProperty
pBidSchedule
pCompanyID ---> tblCompany ---> tblCompanyContacts
The query can be run either way.
THIS IS HOW I WANT TO USE THE BID SCHEDULES. EACH PROPERTY IS UNDER
CONTRACT FOR THEIR LANDSCAPING. AND OBVIOUSLY THOSE CONTRACTS EXPIRE SO
COMPANIES GO TO BID. SOMETIMES A COMPANY CONTACT BIDS ALL THEIR PROPERTIES
AT THE SAME TIME OR SOMETIMES EACH PROPERTY HAS A DIFFERENT BID DATE. I
WANT
TO BE ABLE TO TRACK THAT AND BE ABLE TO SET ALERTS TO REMIND US THAT THOSE
DATES ARE APPROACHING SO WE REMEMBER TO REACH OUT TO THEM VIA THE DIFFERENT
ACTIVITIES OR SUBMIT A BID AT THE RIGHT TIME. SO, I WANT TO HAVE A BID
SCHEDULE FIELD (WHICH WILL SIMPLY BE A DATE) FOR THE COMPANY CONTACTS AND
FOR
EACH PROPERTY. I WANT TO HAVE THE OPTION ON THE PROPERTY TO CHOOSE THE
COMPANY CONTACT BID SCHEDULE DATE OR ENTER A NEW ONE IF THEY ARE DIFFERENT.
SO, ESSENTIALLY THERE IS JUST ONE DATE THAT WILL SHOW UP IN THE BID SCHEDULE
FIELDS. THEY MAY BE DIFFERENT DATES, BUT THEY WILL BE SINGULAR DATES
ALWAYS.
DOES THAT HELP?
--
Gina Whipp
2010 Microsoft MVP (Access)
"I feel I have been denied critical, need to know, information!" - Tremors
II
http://www.regina-whipp.com/index_files/TipList.htm
Hello again! Did you get a chance to review the questions from my 1/26 post
from this string?
Thanks again!
Ellen
I guess you can't see my answer so I am reposting...
********
Okay... no worries about the all caps... I hate it also, looks like
yelling, but I get why you did it.
Right now, I just want to focus on the Bid Schedule so I can get that thru
my *thick* head and then I'll deal with the other questions/comments...
So, if I understand the below... The Bid Schedule is attached to the
Property and there will always be only one date in that field. If that is
true then it only needs to be in tblProperty. Having it in tblCompany
serves no purpose unless I missed something.
tblProperty
pBidSchedule
pCompanyID ---> tblCompanyContacts (ccCompanyID)
OR
tblProperty
pBidSchedule
pCompanyID ---> tblCompany ---> tblCompanyContacts
The query can be run either way.
THIS IS HOW I WANT TO USE THE BID SCHEDULES. EACH PROPERTY IS UNDER
CONTRACT FOR THEIR LANDSCAPING. AND OBVIOUSLY THOSE CONTRACTS EXPIRE SO
COMPANIES GO TO BID. SOMETIMES A COMPANY CONTACT BIDS ALL THEIR PROPERTIES
AT THE SAME TIME OR SOMETIMES EACH PROPERTY HAS A DIFFERENT BID DATE. I
WANT
TO BE ABLE TO TRACK THAT AND BE ABLE TO SET ALERTS TO REMIND US THAT THOSE
DATES ARE APPROACHING SO WE REMEMBER TO REACH OUT TO THEM VIA THE DIFFERENT
ACTIVITIES OR SUBMIT A BID AT THE RIGHT TIME. SO, I WANT TO HAVE A BID
SCHEDULE FIELD (WHICH WILL SIMPLY BE A DATE) FOR THE COMPANY CONTACTS AND
FOR
EACH PROPERTY. I WANT TO HAVE THE OPTION ON THE PROPERTY TO CHOOSE THE
COMPANY CONTACT BID SCHEDULE DATE OR ENTER A NEW ONE IF THEY ARE DIFFERENT.
SO, ESSENTIALLY THERE IS JUST ONE DATE THAT WILL SHOW UP IN THE BID SCHEDULE
FIELDS. THEY MAY BE DIFFERENT DATES, BUT THEY WILL BE SINGULAR DATES
ALWAYS.
DOES THAT HELP?
--
Gina Whipp
2010 Microsoft MVP (Access)
"I feel I have been denied critical, need to know, information!" - Tremors
II
http://www.regina-whipp.com/index_files/TipList.htm
Hello again! Did you get a chance to review the questions from my 1/26 post
from this string?
Thanks again!
Ellen
T
TGC
Here is the catch with that...
Sometimes when we are looking up prospective clients, we have all the info
for the company and the contact, but no info for the property. So if that is
the case, we will direct all our efforts towards the contact. One of our
first questions is, "when do you go to bid?" So, I want to be able to put
the bid schedule under the contact and then have the ability to choose that
same bid schedule for each property or have a different bid schedule for the
property if the contact does not bid all their properties at once.
Does that make sense?
Sometimes when we are looking up prospective clients, we have all the info
for the company and the contact, but no info for the property. So if that is
the case, we will direct all our efforts towards the contact. One of our
first questions is, "when do you go to bid?" So, I want to be able to put
the bid schedule under the contact and then have the ability to choose that
same bid schedule for each property or have a different bid schedule for the
property if the contact does not bid all their properties at once.
Does that make sense?
G
Gina Whipp
Okay, now I get it... <scratching head> but thinking having it in two
tables is the way to go. Now, I have to go look at the table structure and
make sure all is right in the world but I believe that was the last hiccup!
--
Gina Whipp
2010 Microsoft MVP (Access)
"I feel I have been denied critical, need to know, information!" - Tremors
II
http://www.regina-whipp.com/index_files/TipList.htm
Here is the catch with that...
Sometimes when we are looking up prospective clients, we have all the info
for the company and the contact, but no info for the property. So if that
is
the case, we will direct all our efforts towards the contact. One of our
first questions is, "when do you go to bid?" So, I want to be able to put
the bid schedule under the contact and then have the ability to choose that
same bid schedule for each property or have a different bid schedule for the
property if the contact does not bid all their properties at once.
Does that make sense?
tables is the way to go. Now, I have to go look at the table structure and
make sure all is right in the world but I believe that was the last hiccup!
--
Gina Whipp
2010 Microsoft MVP (Access)
"I feel I have been denied critical, need to know, information!" - Tremors
II
http://www.regina-whipp.com/index_files/TipList.htm
Here is the catch with that...
Sometimes when we are looking up prospective clients, we have all the info
for the company and the contact, but no info for the property. So if that
is
the case, we will direct all our efforts towards the contact. One of our
first questions is, "when do you go to bid?" So, I want to be able to put
the bid schedule under the contact and then have the ability to choose that
same bid schedule for each property or have a different bid schedule for the
property if the contact does not bid all their properties at once.
Does that make sense?