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


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


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

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

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

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


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

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