Hi John,

>Look at all the CLIPPER, DBASE, FOX2.X applications in use and still developed today ? If I go to the cart-centre, the hardresser, lots diverse government applications, they all still have DOS programs. Try to solve the riddle why...

>If your niche is found in legacy tools and apps, go for it.

I do not, I was merely stating that an awfull lot of the world arround as is using legacy apps. I'm mainly talking about DOS programs. The difference between Windows and DOS is far greater than between VFP and .NET.

To some, if you're writing VFP apps, you're already in a niche markted. So what is against niche markets? Niche markets generally are great for your carreer. Look at the good old COBOL programmer earning lots of money.

>I don't see why all full event driven Windows applications, become outdated any time soon. Because there are new technologies like .NET. What does it have to offer towards the users who should work with them ?
>
>Either do I.. I see .NET building these type of apps (windows apps) as well...

So why should I migrate to .NET if I earn my living in writing such apps ?

>>>So, apart from the way you *feel* - what tangible things can you point to?
>>Let's turn arround the question.

>So the answer is no - you can't point to tangible things.

the legacy DOS applications.
Can you point out some things to defend yours ?

>I get the impression you talk about enterprise solutions. I'm talking about more standard software soultions that can be selled more than once. Take accounting software. What does .NET have to offer besides a terrible performance.

>No...I am talking about solutions of all sizes. FWIW, enterprise is an outdated term. And FWIW, .NET does not have terrible performance....

I'm not talking about overall performance, But for certain data intensive applications .NET might not give the optimum performance. If you want to build highly data driven applications .NET might not be the framework of choice either because handling data is from my POV not the most strong part of .NET.

>>Could you base your opinion on facts ? No more than I can, I suppose.
>This is a great way to defend your position... in other words, you claim is that my claim is no more credible than yours. A VERY weak position indeed...

Why weak? You confirm that you cannot prove your opinions are base on facts. Therefore your question was inappropriate at the first place.

>MSDE is incompetent for a wide category of data handling issues. The cause is its set oriented nature; the inability to directly use the internal schema (like indexes) efficiently. There are a lot of identified cases where SEEK, SET ORDER TO, SET RELATION, KEYMATCH, SET NEAR functions beat the hell out of any equivalent in MSDE. I've got an accounting package (DAVILEX BUSINESS) running on MSDE which is slow as hell. You can forget very complex database calculations with MSDE at reasonable performance.

>In a query, I can give the query optimizer hints as to which indexes to use. Also, in MSDE, and SQL Server for that matter, I can do row by row operations.

Optimizers are real performance killers in the type of applications I like to work. They're good in optimizing queries for larger resultsets. They're terrible for looking up just one record in the least time possible. The best performance in VFP you can reach is not using Rushmore at all, but using the index directly (SET ORDER, SEEK, SET NEAR, SCAN WHILE ... FOR, KEYMATCH etc.)

>If the application you are running is slow, I would look first to the DB design, then to the application design. More than likely, those elements are flawed. That is like attacking VFP because somebody wrote a piss-poor application or SQL Server because somebody insists on returning 100,000 rows in a query. Simply put, an argument without merit...

Its not the example I gave, but the technical facts about SQL server that gives VFP a performance advantage in certain cases. SQL server is based on having an external scheme seperated from the internal scheme. Therefore the possibilities to use indexes directly are limited. VFP has no distinction between an internal and external scheme. Does SQL server have equivalents for SET NEAR, SET RELATION, SET ORDER, SEEK and KEYMATCH ? Maybe to some extend, but certainly not in the efficient way VFP manages these commands.

I'm not implying that every application should need these features to optimize performance, But if you have to write some performance critical routine handling data, you're better off in VFP than a SQL based DBMS.

>The xBase approach allows me to handle data, which SQL only dreams about. I've got a leave calculation module handling over 20 tables with complex relations, outputting an array containing the leave hours (of 12 leavesorts) for a whole year for one person in just 5 thousands of a second on my ADM 750. No SQL construction has the possibility to do this under one or two seconds.

>You assume the only language SQL Server is capable of implementing is ANSI SQL. Somehow, the rest of the world manages to do complex tasks in SQL...

on heavy equiped expensive multiprocessor servers, while I manage to do the same on a cheap desktop PC bought in the supermarket.

>My friend, you dearly underestimate the power of the record oriented mechanisms in xBase languages. And yes, I am aware of optimizing SQL statements in a variaty set of DBMSs.

>Record oriented mechanisms exist in SQL....

I'm aware they do, but they are really not worth mentioning it. This might be the reason why, still a lot of mainframes run hierarchical database systems: They perform better than their relational cousins in certain areas.

>It is clear that you are going down a personal road - and with that, I will take my leave of you. This discussion is far too important to get into personal issues....

No intention at all to get personal at all. Just replying to you in the same manner as you replied to me, that's all.

Walter,