Bob,

>>IOW: In most cases I can't sell a SQL server based product. And that is my real world.

>If that's the bottom line, then that's the bottom line. But, that fact doesn't make VFP/DBF solution more flexible and superiot to VFP/SQL Server solutions. Of course there is more to the decision than certian technical issues.

I Never have said that VFP/DBF solutions are more flexible and superior to VFP/SQL Server solutions, never are going to say this. Where in my messages did you read this?

OTOH, I do have to say that a VFP solution (wheter VFP/DBF or VFP/SQL server) is more flexible than just a dumb client (read VB, .NET)/SQL Server. Lets take a VB/SQL database solution where about all data has to be processed on the server:

- You don't have a choice where to process the data: On the server
- You don't have a choice how to process your data: With (T*) SQL (*in the case of MS SQL Server)

Compare this with a VFP solution:

- You have a choice where to process your data: Remote or Local or on any given tier
- You have a choice how to process your data: Record oriented (VFP++, SQL-) or Set Oriented (VFP+, SQL++)
- You have a choice how to store your data: DBF, Cursor or in the SQL server database.

You do not have to be a genious to see what is the more flexible and powerfull solution. The consequenses are enormous.

Also, I outlined that a record oriented approach that can be used with DBFs, but also with cursors obtained from a SQL Server, can be superiour and more flexible than the SQL Server only way in certain record oriented or hierarchical problems.

>Not at all, I have VFP for client side data, and SQL Server for server side data. To me, this has been a 'best of both worlds' scenerio.

Indeed it is. I never am going to dispute that.

>I can choose the proper tier to do the work at hand, the server for large/batch processing jobs, the client for UI and UI Layer Validation (2-tier).

I would not burden the server too much for batch processing jobs, but throw in another tier (or seperate application) to do the job for you. The SQL server must not be loaded under work that can be done on other tiers. IMO many batch processing jobs are better done in VFP (side of SQL server) than under SQL server (Server side) because of the data munging nature of many batch processes.

>I wouldn't call this fat client or fat server, I would call it right size client, right sized server.

I think we are not going to agree on that. It is a traditional C/S configuration which means FAT client. However throw in TS, and you're suddenly talking about a thin client, 3 tier solution.

Walter,