But that;s the point. In .net you pull the data and you populate the control - seperate steps. Get all the data in one trip, then populate the controls. ADO worlks differently from Fox. There is a lot of power in the disconnected nature of ADO data. You can return multiple cursors with a single sproc - one trip to the server - and then fill multiple datatables from that sproc from which you fill your controls., It is more efficient than 25 trips.

One of the big myths that has lived in our community for too long is that Fox "handles data" better than .NET. Just isn't true. I handles it differently and there are strengths and weaknesses on both sides, but once you really get your head into the .NET way of doing things you'll find the advantages can be very great.

I have one app that needs lookup data from 37 different lookup tables. All of that is pulled into business objects with strongly typed properties with one call to one sproc when the app starts up. After that I'm working with local cursors on instantiating every control on ever form that needs them - or just using them "under the hood" for calculation or validation.


>Thank you for your useful input. In my case, all of the lookup table controls are populated on form being instantiated. And since each control is instantiated separately, it would be the same number of trips to the server - regardless if I keep the data in one table or in many tables. My main consideration for breaking one table into many is 1)easier to have RI 2)not "aggravating" DBA with bad design.
>
>
>>I think the first factor to be considered is how many trips to the server will be required to retrieve lookup data.
>>
>>If you know you need 25 different lookup tables every time you bring up your app, or a particular form, ideally you'll retrieve everything on one trip. Personally, I keep the tables granular but grab all the data with one sproc to fill 25 business objects.
>>
>>Having all of it in one table makes writing the sproc easier, you just have to parse out the result.
>>
>>But think in terms of reducing server trips. It's called "chunky".
>>
>>
>>>Hi,
>>>
>>>I don't know if this question was asked before (maybe even by me <g>) but I came across this issue again in converting from VFP data to SQL Server database.
>>>
>>>From the times when I was working in Clipper (and moved the app to VFP 6.0) I had a limit on number of handles could be used when opening tables, I have one table that is sort of a "container" for many "lookup" tables. The table structure is:
>>>
>>>TBL_ALIAS, C, 20
>>>ENTRY, C, 20
>>>DESCR, C, 40.
>>>
>>>By making different entries in TBL_ALIAS I can actually store many different (mostly lookup) tables in this "all-purpose" lookup table.
>>>
>>>When moving the app to SQL Server, creating another 20-25 small tables does not seem to be a problem. Hopefully it will not cause too much extra load on SQL Server (vs. having to deal with just one table).
>>>
>>>But my question is in general, what is a good practice - when creating a new application in SQL Server - using a separate table for each small lookup or combining them into one (as I did back in DOS times)?
>>>
>>>TIA