Martin,

>>In the sample in the MSDN it demonstrates how to create and work with a web service using a single table and the objects on the front end are binded to the dataset. Would there be any issues if I follow this method for now since I am not that familiar with the Web Service?<

Well, since I don't know which MSDN sample you are referring to, I don't know what issues you might be talking about. There is certainly nothing wrong with a Web Service returning a DataSet with one table or 100 tables. BTW, you will get mixed opinions on whether it's a good idea to have your Web Service deal with DataSets or XML (using a the DataSet.GetXml() method). I prefer to use XML.

>Or does it get the complete records and filter it locally (thus fetching the records only once). If it is the second, that is happening then that would not be good right?<

The way you've just described it, you are filling the DataSet with all the records from all the tables and just filtering them locally. With the amount of data that you are pulling down, this is probably not what you want to do.

>>Although, I did put the .fill(ds) command on the selection changed event of the first combo. So thinking out loud this is working in the way that you suggested. Right?<

No. Now you've totally lost me. How can you have a DataAdapter.Fill(ds) in the UI if you're using a Web Service? The DataAdapter belongs server-side, not client-side.

>Maintenance wise, is it easy to manage this kind of setup? Like if I make changes on the WebService (assuming that I do stick to WinForms), would I need to refresh the reference to the web service on the client apps?<

No, you don't need to do anything to the client apps assuming that you don't break the interface of the Web Service methods. By that I mean that if your UI is calling a Web Service method that expects to have 3 parameters, you can't change that Web Service method to use 4 parameters. That breaks the interface. Once you do that, you would have to change your UI.


~~Bonnie



>Bonnie,
>
>>It sounds like you have a lot of data to bring down and, since you're getting data based on what the user chooses from a Combo, I would not get it all at once. Get the data to fill the first Combo. Once the user makes a choice from that Combo, get the data that fills the 2nd Combo based on that choice (so, only the regions for that country). And the same for the third Combo. This is not an unreasonable design and should be relatively fast.
>
>In the sample in the MSDN it demonstrates how to create and work with a web service using a single table and the objects on the front end are binded to the dataset. Would there be any issues if I follow this method for now since I am not that familiar with the Web Service?
>
>Also when I tried to play around with master-slave tables. I defined the relationship on the dataset on web service using the relationship object. For the second combo box, I bounded it to the relationship so that when the user selects a country from the 1st combo box, the second would automatically display the child records. I'm not kinda sure of what is going on here though. I was just curious if this has the same effect as what you were asking me to do? Or does it get the complete records and filter it locally (thus fetching the records only once). If it is the second, that is happening then that would not be good right?
>
>Although, I did put the .fill(ds) command on the selection changed event of the first combo. So thinking out loud this is working in the way that you suggested. Right?
>
>Maintenance wise, is it easy to manage this kind of setup? Like if I make changes on the WebService (assuming that I do stick to WinForms), would I need to refresh the reference to the web service on the client apps?
>
>The questions keep growing in my head everytime I get an answer to one... 8 )
>
>
>Thanx! for the help 8 )
>
>Martin