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

A monotologic app. You don't need to register anything, just put all in a single dir and it works.

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

I don't agree. Processing data can happen in all layers. From GUI to data. I find this a classical example of getting the wrong Idea of n-tier solutions. a buisiness object can supply you with the basic data that you need. At the GUI or other upper layer you can transform the data into any form you need. This is an effictive way to make advantage of the enourmous distributed processing power. Why should you mung your data into a reportable form in the data layer. If this data layer is centralized on a single server, you're unnesarely loading the server with tasks that could be performed at the client (or upper layer) as well.

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

.MDB files belong to an access database and with a SQL server (whether it is SQL-server, Oracle, DB2) the data is store on the same machine as the SQL server process is running on. As a note, IMO MySQL is not a full featured database 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?

Flexibility has to do with the circumstances where it makes sense to use it. It does not make sence to use a SQL server for applications which by nature do not need such horsepower.

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

I was refering to the fact that in a VFP database you can store more data than in a MSDE database, though its table size is limited to 2GB.

>>6. Fox databases are less suspectible to security issues or virusses.
>You're not saying Fox dbf is MORE secure are you?

No, I'm not. With SQL server database there are a lot of things that can happen which leads to dropping the database offline. (Service won't start, virusses, Security problems). Drop a DBF file anywhere and you can use it.

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

You're correct that DBF database are more suspectible to corruption in about every form. Using a SQL server certainly has the advantage here. However, as I have been saying before, it is about the way you code. Using transactions and databuffering are excellent tools to minimize the problems. About integrity: I don't fully agree in VFP you can use the RI builder to set up your integrity and in both circumstances you have to setup the integrity anyways. I don't see the advantage here that much.

About programming time. There are a lot more issues involved regarding productity difference. I don't believe that a the bottom line the use of a SQL - Server database is more productive. In VFP you've got it all intergrated. Via the program manager you can create and maintain your databases with a VFP -SQL server you've got to go to both VFP and the Database manager and all that lies in between (e.g. ODBC, OLEDB, ADO etc).

>>7. Fox has a far stronger DML for record oriented processing.
>SQL has far stronger DML for set based processing. So what!

Absolutely. But in cases where you need a record otiented approach you at least are not force in workarrounding the issue. Please note that in VFP9 VFPs set oriented functions will be greatly improved.

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

AFAIK, It is an hint, not a way of bypassing the optimizer at all and directly searching through the index unconditionally. The fact is that with the SELECT statement it is going to be processed though a number of layers which are not present in a SEEK command.

>>9. You can use filtered indexes
>You can create an Indexed view in SQL Server, same thing basically.

I don't think they fully compare. You're talking about a view that can be indexed. I'm talking about indexing the table itself. However I have to agree that I cannot overview what this would mean in real practise though.

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

I fully disagree here. Try to do this on a appache or Novell server. Also, the requirements of a fileserver is totally different than that of a database server. Also note that it is not recommended to install a database server on a PDC or file server.

>>11. You can create portable applications (MSDE see point 5)
>I assume you mean 'disconnected' ???

Not neccesarely, Just a single application on a laptop. Though my applications are ment to run in a multiuser environment, I have all my applications on my laptop and can run, demo and develop from there. I don't have to use MSDE or SQL server on my laptop.

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

I disagree, handling data is somthing that occurs in all layers not something you are describing as a data layer. (where would you put the business logic BTW). The data layer might be responsible of writing and retrieving data from a central layer and abstracts the data backend from the other layers, but it is by no means a rule that all data processing should occur on the data layer. And as I stated before ADO.NET is not a local database engine.

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

Compared to what. Do you've got an example. Datamunging on a record oriented basis is by definition cumbersome in SQL. One SQL implementation might have better propetary mechanisms than others, but in general VFPs record oriented DML wins hands down on record oriented problems.

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

It's is about decentralize processing power. In a traditional C/S application the data handling is done on the server while the clients do little more than handling the GUI. In today's workstation processing power you can define strategies where you can take advantage of the clients processing power to mung data. For example, I don't see why data munging for reports should take place in a database server (and therefore might block concurrency). You're unneccesary using server resources for tasks that could be easely done by the client, by using a local database engine. This is an area where VFP really shines, and is highly underestimated in the .NET world.

>>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 don't know how this exactly relates to this point, but the fact is that from a developer standpoint of view learning one product is far more productive than two and learn how they match.

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

All I want to point out is that there are applications which are better done by VFPs record oriented approach and some other application are better served with a certalized solution on a database server. However the advantage with a product like VFP is that you can choose:

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

This is accomplished by:
1. The set orient approach of either VFP or SQL server
2. The record oriented approach of VFP.
3. Deciding where to process it: At the client or in another layer (e.g.: SQL server, buisiness object layer in a n-tier solution)

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

- Both a strong local and remote database engine.
- Can create COM layers.
- Can handle both SET and record oriented problems efficiently.

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

Walter,