I am put up in a situation to handle the following activity.

There is a select box which has client ids taken from database, upon selection of an ID, there is another select box, which should show only the information related to the selected Client ID's which should again be retrieved from database.

Kindly let me know, how to sort out this problem.


There are 3 select boxes that are dependent on one another.

After you select an ID from the first SELECT BOX, you need to reload the page and then you can have the information about this ID.

If the page is reloaded as you said, The select items also gets reloaded and is pointing to the first one in the select box.

Also tell me what is the right method of reloading with code so that i could try it out

You do not need to reload the page, you need to submit the form.

Erm, use javascript to submit it. Put it in the on_change method of the select element, the form will then submit when the selection is changed; thus passing the value back. you can then disable this element and run the query for the next select element with the data passed.

"Reload" means to submit the form using JavaScript and then the page will be reloaded. So at the beginning of the code, you need to get the value from the first dropdown list and pass it to the second one. So in the second dropdown list, the values is listed based on the first one.

Maybe I'm just an old "don't like to use much code" kinda designer, but can you do better than the approach that's being used right now, right in front of your nose, by this very piece of forum software?

At the top of my screen I see:
dBforums » Data Access, Manipulation & Batch Languages » ASP » Handling Multiple Select Queries

Each of these will take me directly out to the appropriate level of the heirarchy while clearly visualizing its presence to me. You can do exactly the same kind of thing, and be displaying only one list-box or combo-box (the current one) in front of my face at one time. And now, over my slow-but-typical 56K modem line that the local telephone company only drives at 33K, I'm only having to wait to download the HTML for one combo-box, not three and a bunch of Javascript (VB?) code.

The interaction between a user and an application, over the Internet via HTML, isn't the same as that of an interactive application-program. If you try to make it too-much so, you create a system that is very unwieldy and, worst of all, browser-specific and browser-version specific. If you're not careful, you'll be rewarded with a maintenance nightmare that never really does work as it should.

To be sure, you can do that whether you're using ASP or PHP or Perl or what-have-you, but I think the temptation might be worst for ASP designers. Those people tend to be "very Microsoft-centric," almost invariably using the latest version of "Microsoft, of course! (What else is there?)" operating systems on their oh-so-fast computers with oh-so-much memory and a T-1 line. And they design design systems that break down utterly under, say, "Netscape on Windows 98." Now I'm not here to throw hot coals or anything of the sort, but rather to point out that (imho, of course) why they get into trouble is that they build systems that are very complicated, relying on a great deal of client-side programming as well as server stuff. Bad news! Turns out (imho) that you can never really predict what environment the user is running, and never really can debug it.

Customers don't wait. Your site's one of about 175,000 on Google's search results, and does he really care which one he buys from? Yup, the first one that works. "He comes, he tries it, it don't work, buh-bye!"