>>There are several ways to get at your data in C/S applications.
>>- ADO record sets
>>- SQL Passthrough
>>- Remote views
>>
>>While not necessarily the best choice of the three, remote views are probably the easiest to implement. You must use SQL commands exclusively for all data access/updates/adds/deletes. You can index the cursor/view once you get it.
>
>My question was more about the interface design, rather than the technical part. Let me give an example of what I don't know how it's handled in client server :
>- consider 2 forms : one that updates a product table containing 30000 products and a form that updates a supplier table conaining 500 suppliers. I imagine that pulling the whole supplier table to the client (and indexing if needed) isn't much problem but what with the product file ? Pull the 30000 products in to work on it ?
>- consider an invoicing program using the products table. Inputting the productcodes by productcode and allowing a search on productdescription (amongst others) : again pull down the complete products table to the client ?
>
>Having these tables on a local VFP database gives lots of possibilities but I don't know how to handle things in C/S ...


You should only ever work with a subset of the data. For example, the user enters the supplier id. The record for that one supplier is pulled back. Or the user can request to get all suppliers in New York. This gets you a subset of data. The previous/next buttons we're all used to then work on that set of data, not the entire table. If you need to supply a search by product description, the user can enter the first part of description, then pull back the records that match what the user entered.