>1. Using an install of a single zipfile and make the application work on a number of windows versions.

Are you talking about the app, or the server.

>2. You can decide to do the processing of the data of any layer in an n-tier solution.

Data processing belongs in the data layer.

>3. You can use DBF tables stored on a linux server.

Ever hear of MySQL, Oracle? As a matter of fact, you can run SQL server on an Windows maching and put the .mdb on a linux server.

>4. You don´t need a license for SQL server nor the connection licenses, so cheaper.

What does 'flexability' have to do with price?

>5. When throwing in MSDE: Fox does not have a database limit.

Huh? Each table has a maximum size limit. In MSDE each database does, even SQL Server has a limit. So what? In Foxpro you add a table, in MSDE you add a database.

>6. Fox databases are less suspectible to security issues or virusses.

You're not saying Fox dbf is MORE secure are you?

DBF's are more suseptable to corruption and bad integrity. You have to also deal with most of these issue in your application rather than the data engine dealing with it natively, which means more code and time.

>7. Fox has a far stronger DML for record oriented processing.

SQL has far stronger DML for set based processing. So what!

>8. you can use indexes directly, bypassing the optimizer

You can in SQL too, with an optimizer hint you can tell it what index to use.

>9. You can use filtered indexes

You can create an Indexed view in SQL Server, same thing basically.

>10. You don´t need server hardware for an application.

You usually put your files on a shared machine, might as well run SQL server on it.

>11. You can create portable applications (MSDE see point 5)

I assume you mean 'disconnected' ???

>12. VFP has integrated relational data handling as no other product I know. ADO is just cumbersome.

ADO.Net is much better, but once again, you do your data processing in the data layer.

>13. Datamunging is far superiour with VFPs richs set of both set and record oriented DML.

I've done much more difficult stuff in SQL with alot less code. Although I admit that VFP's string and date handeling is much better.

>14. With VFP applications the performance of the datamunging is depended on the client. In a SQL server on the performance of the SQL server. This might be an advantage when a lot of data munging has to be done on a large number of clients. The server won´t be a bottleneck as easy.

Are you proving SQL's point... much easier to scale a ap when you are only dealing with one machine.

>15. With VFP you can create a solution within one product. With SQL server you still need a front-end.

Apples are read and Oranges are orange.

>I could come up with far more difference. I could come up with the same number of advantages of SQL server, but this is already know at your side I assume....

Ok, how about some that aren't biased toward VFP. You can't say, VFP is better at record by record processing... sure it is, that's it's design. Does this mean the solution you create is better if you do it record by record and I do it with a set based command?

>Of course a SQL server has its advantages also.

Yes, it does.

BOb