>Erik,
>
>>If Josh's app uses strictly views (even for lookup tables), then he can switch to remote views without changing a single line of code in his forms.
>
>Someday I'll probably need to get around in a wheelchair, with a catheter, but I'm not getting fitted for them today. Don't _burden_ yourself with something you don't currently need.

My point is, its _not_ a burden if you are already in the habit of doing it. It is only a PITA if you are unfamiliar with the technique, or you have a messy mixture of architectures that uses views in some places and tables in other, with no discernable guidelines as to which is which. For me, views cost nothing over tables.

There are times when parameterized views are essential (forget about the C/S argument) Have you ever tried to build a one-to-many-to-many form incorporating a grandparent-parent-child relationship? If you have and you tried it using filters or linkmaster grids or even SET RELATION, you know that it is a nightmare to the extent of being next to impossible. But using parameterized views makes it simple and fast.

I'm sure you know the utility of views, but I guess my stance is that if you are going to use views anywhere, you might as well use them everywhere.

>Why not develop a transport object that allows dozens of identically formatted DBCs -- for multiple datasets -- to move the data to/from the backend. This allows you users the speed of VFP native and security/size of Oracle/Sybase/SQL Server. This allows the DBC to act as a "view" for many users, rather than each needing their own. The middle tier -- transort object -- not only performs validation, but also only needs a single client connection, rather than your way whicj would require a connection for each user. More at http://www.temperedsys.com/UFACS.htm

Not sure I follow this... could you expand? Or should I just follow this link..

>
>>The client server mentality is based on the premise that the user has an idea what he wants to see before he sees it, and in the real world...snip
>
>In the real world prepare for users _thinking_ they know what they want and then changing their minds!
>

An intelligently designed UI will provide for this. The first VFP app I built was for an association that had at the time the need for a table with about 50000 records in it. Two years later the size of this table has grown to over 320,000 records. The original picklist design used a grid with incremental search that was based on the table directly. As the months rolled on, this form became too slow almost to the point of being unusable, because of its very design. 320,000 is just too many records to come over the wire, especially when 50+ users are hitting it at the same time. If the form had been originally designed with efficiency in mind, I wouldn't have had to go back in and redesign it. That was the last time I'll make that mistake.

>>For lookup tables I issue a straight SQL in the Init (or ReQuery if the contents are based on the value of another control).
>>
>>Try this with MS Access data on the back end.
>
>I wouldn't dream of it!

I hope I never have to either, but we don't always have a choice.