Hi Bob,

>>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.'

By clumsy I mean for example the solution Rod has given for the exersize of solving hierarchical problems. You'll have to use a SQL SELECT statement that has overhead and use recursive routines. Compared to the very simple VFP construct it is IMO 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.

You mean should not be ignored? A lot of these features are fairly simple to accomplish with a VFP solution also.

- Security can be reached by using COM/DCOM/COM+/remote control/ layers which shields the database from the user.
- integraty: I'm not sure what you mean by this. Examples please.
- Maintainability: In what respect should a VFP solution not be maintainable ?
- connectability: In what sense. VFP databases are fairly open and easy to access ?

>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.

I think you've read the wrong message. I never wanted to imply that a SQL server is not able to accomplish something, but its solution is by far not as optimal and efficient as the VFP one. Also note that I try to keep this general and not to a specific SQL server implementation like MS SQLServer 2000, but more in a general sense that also applies to other Server RDMBS like oracle, DB2, Sybase etc. The examples I gave were ment to see what the SQL Server pros could come up with and my intention was to discuss the outcome in comparison to the VFP solution.

Also, don't forget that when I make a statment that SQL is terrible in solving hierarchical solutions I refer to the ANSI standard and not to a propetary implementation of MS SQL sever or addons to its definition like the case in TSQL. The SQL standard is by its set oriented nature less capable of solving hierarchical problem.

>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.

I serves another purpose as well. Index views are optmizing tools used in SQL queries. Filtered indexes are a bit more limited as they are ignored by the optimizer. However a good example of where filtered indexes are usefull is : INDEX ON .T. FOR Delete() to efficently search for deleted records (without a INDEX ON DELETED()).

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

Only where it makes sense. For enterprise apps, SQL server is certainly a possibility that should not be ignored, but certainly do not overvalue SQL server to push it in cases where a VFP only solution is simply more practical.

Walter,