John

Not long ago, Oracle bet substantial sums of money (a billion dollars from memory) that its latest offerings would be at least ten times as fast as similar development with other product, including SQL server.

If Oracle is correct, developers firmly fixed to other backends because they use proprietary "high performance" features, may soon be hoist by their own petard.

In contrast, a VFP developer using the "miserable" parameterised query system and whose clients are determined to use Oracle may well be able to participate by pointing his or her views at Oracle, then going and playing with the kids because the task is complete.

This is why I do not agree with your repeated absolute assertions in this area. Your viewpoint is only "Absolute" if your chosen backend is far and away the best, will always be the best, and is preferred by every current and future client any of us may ever encounter. If this is not the case now or in the future, the decision to tie oneself to a single backend may be just as silly as a VFP developer who does everything with seeks and locates and is thus tied to local tables with all their deficiencies. The justification is the same (better performance today, easier) but that is valid only while the underlying choice is valid.

Plus, if one were really determined to tie oneself to a single database in the year 2000, SQL Server is a strong option but it is far from the only option.

I would recommend that SQL Server developers look at the Cache database from Intersystems. We've done a bit of work with them on SQL Server equivalence. Cache is a post-relational database with a pretty good SQL parser built in. In tests it is *visibly* quicker than SQL Server. One of our big British hospital clients runs the whole place with a single Pentium Pro 200 Server. If the arguments for SQL Server are as purely technical as we are told, perhaps Cache should expect a lot of new business soon.

Regards

JR