Combobox and eventhandler

[Lubomir]

Hi,

I have a combobox and datagrid in a form. When an Item is selected from a
combobox, a method is called, which will make selection from a database
according selected item and populate datagrid.

I used comboBoxLastNam e_SelectedValue Changed handler, but this handler is
called for every Item when combobox is initialized at the start. It means
there is made database access for every item, which is not needed and slows
down application.

What is the best place for calling that method?

Thank you.

Lubomir

[William Ryan eMVP]

Hitting the db each time anything happens, regardless of the event, is
probably a bad idea. The shortcut way would be to define a flag and just
e.Cancel the event if that flag isn't set. When the form is done
initializing then go ahead and set the flag. The order of what happens and
what events fire when the form is initializing isn't a constant thing so
it's pretty hard to handle otherwise. So basically, at the end of the form
loading, set IsLoading to false. Then in your event handler,
if(IsLoading)re turn;

Ok, now for the real problem. If you are hitting the db each time a combobox
value is selected, you are defintiely wasting a lot of resources and it's a
rare scenario indeed where this is necessary. For instance, if I select the
first value in the combobox, then realize I made a mistake and try to click
the second one, and then realize it was actually the first one after all
taht I wanted, I just made three trips to the DB. This may not appear to be
really wasteful if I only have a few users, but as the user base grows, this
type of approach will not scale. I would consider (depending on the schema
of the db), pulling over the parent and child tables (if they fit that
paradigm) or pulling over the respective tables at once. If they fit the
parent child model, I'd link them w/ a datarelation and set the bindings
accordingly - this way I don't have to make a trip back to the db each time.
http://www.knowdotnet.com/articles/datarelation.html If they don't fit this
model, I'd consider binding to a dataview for instance and setting the
RowFilter property (or use Find or Datatable.Selec t)
http://www.knowdotnet.com/articles/expressions.html
http://www.knowdotnet.com/articles/adopartiii.html

And even if you must go to the db, I'd use some structure of my own if I
couldn't use a DataTable or a View to hold values that I already retrieved
so that if the users selects soemthing they already selected, I can just
grab it from the local store and save a trip to the db and all of the
overhead associated with it.

HTH,

Bill

--
W.G. Ryan MVP Windows - Embedded

Have an opinion on the effectiveness of Microsoft Embedded newsgroups?
Let Microsoft know!
https://www.windowsembeddedeval.com/...ity/newsgroups
"Lubomir" <Lu*****@discus sions.microsoft .com> wrote in message
news:1E******** *************** ***********@mic rosoft.com...

Hi,

I have a combobox and datagrid in a form. When an Item is selected from a
combobox, a method is called, which will make selection from a database
according selected item and populate datagrid.

I used comboBoxLastNam e_SelectedValue Changed handler, but this handler is
called for every Item when combobox is initialized at the start. It means
there is made database access for every item, which is not needed and slows down application.

What is the best place for calling that method?

Thank you.

Lubomir

[David]

On 2004-08-16, William Ryan eMVP <do********@com cast.nospam.net > wrote:

Ok, now for the real problem. If you are hitting the db each time a combobox
value is selected, you are defintiely wasting a lot of resources and it's a
rare scenario indeed where this is necessary.
I'd disagree there, but it's pretty hard to define "rare". Choices like
this obviously depend on the app.

But in my experience, it's pretty common to have the situation where
pulling down complete tables isn't a reasonable option. Startup time
and memory usage can skyrocket if one uses your approach.
For instance, if I select the
first value in the combobox, then realize I made a mistake and try to click
the second one, and then realize it was actually the first one after all
taht I wanted, I just made three trips to the DB.
Agreed, a simple caching scheme is reasonable here.
This may not appear to be
really wasteful if I only have a few users, but as the user base grows, this
type of approach will not scale. I would consider (depending on the schema
of the db), pulling over the parent and child tables (if they fit that
paradigm) or pulling over the respective tables at once.

If scalability is the issue, having every client that connects pull down
complete tables is unlikely to be the solution, unless your app fits
some very narrow assumptions. And regardless of scalability, stale data
may be a serious issue, which may preclude the option of caching the
complete dataset.

I can easily imagine apps where this approach is the correct one, just
as I can easily imagine apps where this approach is a very bad idea.
I've worked on both. It all depends on dataset size, user base size,
type of application, requirements, phase of the moon, etc.

I agree that caching the complete dataset is an idea worth considering,
but I don't believe it should be presented as an approach that's almost
universally correct.

[Lubomir]

Hi,
Thanks for your answers (William and David). Yes, I used parent/child
relations ship and I defined a row filter for a combobox. However there are
more comboboxex, which are used when it is needed to change a criteria for a
SELECT statement. This is the case, when it is needed to access the database.

Yes, I agree, a combo box is too easy way to a database, and I will consider
to put there a button, that will be needed to click after the selection in
combobox was made.

I don't think this application will be used by more than 5 people at the
same time, but the one never knows... :-)

Thanks for your ideas.

Lubomir
"David" wrote:

On 2004-08-16, William Ryan eMVP <do********@com cast.nospam.net > wrote:

Ok, now for the real problem. If you are hitting the db each time a combobox
value is selected, you are defintiely wasting a lot of resources and it's a
rare scenario indeed where this is necessary.

I'd disagree there, but it's pretty hard to define "rare". Choices like
this obviously depend on the app.

But in my experience, it's pretty common to have the situation where
pulling down complete tables isn't a reasonable option. Startup time
and memory usage can skyrocket if one uses your approach.

For instance, if I select the
first value in the combobox, then realize I made a mistake and try to click
the second one, and then realize it was actually the first one after all
taht I wanted, I just made three trips to the DB.

Agreed, a simple caching scheme is reasonable here.

This may not appear to be
really wasteful if I only have a few users, but as the user base grows, this
type of approach will not scale. I would consider (depending on the schema
of the db), pulling over the parent and child tables (if they fit that
paradigm) or pulling over the respective tables at once.

If scalability is the issue, having every client that connects pull down
complete tables is unlikely to be the solution, unless your app fits
some very narrow assumptions. And regardless of scalability, stale data
may be a serious issue, which may preclude the option of caching the
complete dataset.

I can easily imagine apps where this approach is the correct one, just
as I can easily imagine apps where this approach is a very bad idea.
I've worked on both. It all depends on dataset size, user base size,
type of application, requirements, phase of the moon, etc.

I agree that caching the complete dataset is an idea worth considering,
but I don't believe it should be presented as an approach that's almost
universally correct.