Loading columns in combo boxes

[Al]

Hello,
I was wondering if there are any ill effects to the procedure of loading
about 8 columns of data into a combo box, then using the user's choice in
the first colmn (visible) to fill other text boxes on the form, with the
data in the other columns (not visible)?

The list pulled up by the combo box may have 100 or so records of prices,
10 character strings, etc - nothing heavy.

I use it as a pretty quick way of populating text boxes, based on the
user action and haven't had any problems in the past, but thought I'd
check, nonetheless.

Any better ways I should be doing this?
Thanks,
Al

 

[Marshall Barton]

Hello,
I was wondering if there are any ill effects to the procedure of loading
about 8 columns of data into a combo box, then using the user's choice in
the first colmn (visible) to fill other text boxes on the form, with the
data in the other columns (not visible)?

The list pulled up by the combo box may have 100 or so records of prices,
10 character strings, etc - nothing heavy.

I use it as a pretty quick way of populating text boxes, based on the
user action and haven't had any problems in the past, but thought I'd
check, nonetheless.

Assuming you only want to display the combo box's data, your
text boxes only need to refer to the columns:
=combobox.Column(N)

This arrangement is quite common and is often recommended.

 

[Al]

Hello Marshall,
When you say "only display", you mean putting the info into unbound
boxes?

Actually, as Rick assumed I was using this as a means to kickoff the form
with some data, once the user makes the important choice. Really all I
need is the data from two columns, but the rest gives the user a quick
visual check that what they're doing is right - and by putting the data
into the table, it gives me a very quick way to ensure that the data is
going into the right place.

I realize that this makes the tables quasi-normalized at best, and and I
plan to tighten things up, later, but just want to get this up and
running and have a quick visual that everything is being put where it
should be. I thought for 8 fields it wouldn't be too much of problem.

Thanks for the feedback, both of you!!
Al

 

[Marshall Barton]

By "only display" I meant that the text boxes would
display, without using any code, the values from the combo
box, but would not save them anywhere.

If you are only setting user overidable default values for
new records, then you should use code to set the bound text
box's DefaultValue property.

Otherwise, the only value that might(?) be saved in the
form's table is the combo box's row source table's key
value. This would normally mean that the combo box is the
only bound control under discussion here. If you want to
check the combo box bound column value, then a query that
joins your form's table to the combo box's row source table
should be able to display whatever you want from both
tables.

I'm just having a tough time imagining any reasonable
scenario where putting extra, temporary values in a table
serves any purpose beyond causing future problems or at
least the extra effort to remove them.

 

[Al]

Hello Marshall,

When I say temporary, I could mean months - I really wanted to see how
much data will accumulate into the table to see if its worth normalizing,
as the main reason for loading this particular table is for reporting
information for one user - but if other users start doing this task, then
I will have to make it a lot more efficent, I'm sure.

I posted the message to see if my "quickie" way of loading info into the
table was ok or is wildly inefficient vs. time to setup, and/or if there
was another quick way to do it, since the user had to make this combo
choice, anyway.

Thanks for taking the time to reply!
Al

 

[Rick Brandt]

Hello Marshall,

When I say temporary, I could mean months - I really wanted to see how
much data will accumulate into the table to see if its worth
normalizing, as the main reason for loading this particular table is
for reporting information for one user - but if other users start
doing this task, then I will have to make it a lot more efficent, I'm
sure.

I posted the message to see if my "quickie" way of loading info into
the table was ok or is wildly inefficient vs. time to setup, and/or
if there was another quick way to do it, since the user had to make
this combo choice, anyway.

Thanks for taking the time to reply!
Al

You can use a query to pull in the related data from both tables rather than
copying it into the one table and base any reports off the query. It is no
harder and takes no more time to do it correctly than it does to do it
incorrectly.

 

[Marshall Barton]

When I say temporary, I could mean months - I really wanted to see how
much data will accumulate into the table to see if its worth normalizing,
as the main reason for loading this particular table is for reporting
information for one user - but if other users start doing this task, then
I will have to make it a lot more efficent, I'm sure.

I posted the message to see if my "quickie" way of loading info into the
table was ok or is wildly inefficient vs. time to setup, and/or if there
was another quick way to do it, since the user had to make this combo
choice, anyway.

What Rick said.

It might not be "wildly inefficient" in terms of execution
time, but it is "wildly inefficient" in terms of your
development time to do things the wrong way and then redo
them properly at a later time. This is especially true if
you add **anything** to your program (reports, forms, other
tables, etc) that uses the original bad design.

Based on a half century of analysis by very smart people,
there is a general law of software development that says:

The "cost" of fixing a problem increases by an
order of magnitude for each stage that has
taken place before the problem is fixed.

The stages of development are often broken down to:
high level requirements
detailed requirements
overall design
detailed design
implementation
strip debugging
unit test
system test
deployment
used in the field

 

[Al]

Hello Rick,
That's great, but I thought that it would be quicker, and for this one
table not too much of a derivation of good practice, to do it this way.

Since the user has to see the related data from the combo choice,
normally I would just keep the boxes unbound, and do a report based on a
query.

It really is just as quick? Hadn't thought so, but glad I asked.
Al

 

[Al]

Hello Marshall,
I understand, and I guess it is a "slippery slope"...
Thanks,
Al