>1. How to process your data: Set oriented or record oriented.
>2. Where you want to process your data: Local or remote.

Absolutly... so, use SQL Server AND VFP and you can do 1 and 2 in either tier you prefer.

You also seem to have this feeling the there are situations the you MUST process record by record. If you know what you are doing in SQL server, these are few and far between. And the UDF's of SQL Server 2000 helped with this issue tremendously.

Although I have done record by record stuff in SQL, and it works fine, I don't really know what you mean by 'clumsy.'

>I'm not suggesting that VFPs advatage is only scoped to VFP, but to all development platforms which can take advantage of:

Ok, you can only compare VFP's data engine vs SQL servers... of course sql server isn't designed to create UI layer. Actually, with the next version you will be able to do your business layer with SQL server too.

>IMO, anyone who is trying to degenerate VFPs database handling capacities should keep this in mind.

Once again, there are situations where you are doing smaller apps, or those those only need DBF's... but, for a midsized to enterprise ap I think the extra security, integraty, maintainability, connectability of SQL Server is something that should be ignored.

I am not disagreeing with the great features of VFP, but you are showing your lack of knowlegde and experience with SQL Server in your messages. You are making assumptions when you say things SQL can't do. For example, an indexed view is exactally the same thing as a filtered index. Granted, the implementation is different, but it provides the same advantages.


>Walter,

So, keep using VFP for UI and middle tier, but embrace what SQL server can do for you as the backend data store.

BOb