Hi Rick,

>It's harder and harder with anything to come up with a 'ground breaking' technology. I mean after all software development works a certain way and it's been around for a long while. I think what's happening now is that Microsoft is trying to make the tools more efficient and more integrated for better or for worse. The stuff in Whidbey (the Whitehorse visual class designers (not UI, but class designers), the various databinding hook up Wizards and mappers and the ever expanding role of Intellisense in the environment are making the process more integrated.

I think I have to disagree. There is still a lot of groundbreaking stuff to do. IMO, it all has to do with the integration of the database in a far more fundamental role:

- The file system should run on a database (So it does not take ages to search for a file somewhere on your machine. It is a shame as it is currently implemented)
- Office should be based on a database (So I can just Query for contact persons and Calendar item, etc (the current implementation is a joke !))
- The OS should run on a database (so that all installed programs don't have to loaded from files all over the HD. e.g. open the dialog to see what is installed on your machine, another thing that I don't understand why it is taking up so much time)

And of course:

- Application development should be way more based on database technology (Don't haunt arround for files, but use repositories).
- Applications should run on database technology, not just using database technology (Look at ERP/ERM software)

Microsoft has a lot to do in this areas, other vendors do have more knowledge on this. But they did buy out navision financials a few years ago, so at least they have some knowledge in house.

>But for core language and development features I think things are pretty stale.

I beg to differ.

>>I seldom or never use UDFs() in SQL commands and try to avoid any functions in there too, for this particular reason.

>You may have that discipline but most people (myself included) often don't have that sort of constraint. For you probably because you're not using VFP data in the first place (SQL right?) - you don't really have a choice. If I'm using VFP data in the first place and I'm pretty sure I won't go to a SQL backend. Especially in light that using UDFs or VFP functoins may reduce the number of queries you have to run in some situations.

Actually most of my projects are still using VFP databases (because they're quite small). It is just a habit and a matter of good practise, trying to avoid UDFs, though I admit I sometimes use expressions like LEFT, RTRIM, PADR, IIF() in there. They're not always translatable into SQL server, but the conversion is not that hard.

>>Currently I see .NET going towards VFP (VFP data features to be implemented in .NET) not the other way arround.

>Again, I'm not sure what it is exactly that is so important in the language that makes VFP so indispensible.

To me it is withouth any doubt the local database engine. Also, a lot of clients still run Win9x.

>I can relate. I have a couple of consumer level applications (Help Builder) that I had at some point considered porting to .NET. But there are a number of issues that would have made this process difficult and ultimately there wasn't going to be a lot of benefit to this process. So the application remains in VFP quirks and all. But ultimately choosing what works best is a choice we luckily all have.

>>I'm a big forestander of avoiding large SPs on the server doing mata munging. SQL servers are tipically not well equiped for doing that. The main problem that these processes require too much resources. Not a problem when only a few processes are running simultaniously, but a big problem in with larger numbers of users all doing their SPs for reporting or other datamunging services. This really becomes a nightmare when the isolation levels need to set high so read and writelocks are going to block other processes (transactions). There are all kinds of other problem with it as well.

>Personally, I actually agree and the truth is I probably use that approach in most of the apps I'm involved in. But for scalable systems using local data processing is often not a good option because you loose control.

Can you give an example ?

>Also, it's important that local .NET data management is not slow per se - it's just slow for certain things in large data scenarios. Those scenarios can often be addressed differently - using data readers and manipulating the data as it comes in. But granted this is more work than using a cursor.

More work is one, but the main problem is that it is not standardized. the SQL dml is standardized. The xBase XML in VFP is the same for all of us. In .NET you are working on a more granular level where every one invents their own, non - standard, solutions. Developpers are more left up to their own creativity and skills to solve (local) data related problems. Simple data concepts in VFP takes a different approach in .NET having to think of how to solve that problem more lower level detail. A simple LOCATE FOR .. WHILE drilling down an index a SEEK, a CALCULATE, a SET FILTER to command takes a whole different approach in .NET, but the solutions to these high level requirements are still left up to wild west programming for all kinds of lowly usable (read specific) solutions.

I see it this way. VFP comes with a RI builder that generates code attached to triggers to maintain referential Integrity. Though the implementation of the code is terrible, everyone could set up RI for their database pretty easily. If VFP did not deliver this tool by standard, everyone was left with roling their own code. Result no standard in RI handling and on the average horrible, inflexible and very buggy RI handling in most VFP applications.

With .NET you have to create your own solutions to DML commands not available in .NET, resulting everyone to create their own, on the average horrible, inflexible buggy classes.

>>Whether you do medium or largish is really not a measure for complexity. Most large applications are basically set up very simply heavely relying on a solid framework. Having a lot of tables, forms, reports, really does not tell you anything.

>True, but I'm talking about data size here. Transactional vs. heavy data processing. Transactional applications are very well suited to .NET. I think the main issue is data processing when you have to process data on the client.

Sure, OLTP (OnLine Transaction Processing)is not a problem, DS (decision support), OTOH is more of a problem. This area of data warehousing has all kinds of scalability issues also because of the issues we described here (e.g. resource intensive SPs). The solutions are sought in creating multi layer applications where the data warehouse is only delivering the RAW data and the middle tiers are responsible for doing the more resource intesinve "data munging tasks". Technically, often, you could solve the problem also to let the client do these processes, eliminating the extra very expensive layer in between. I say technically, because often there are other requirements (security, thin client solutions) that justify such setup, but I wonder how many project structures could just be downgraded to a simple C/S setup where the client plays an important role in this.

>I understand, but again, it might be an issue of perspective of how you choose to do things. I'm not saying that this is wrong, butin some cases you must do things differently with different tools. All it means is that it's not impossible. Here again the server side point would come up if you'd talk to a typical SQL backend person. Not better or worse, but different.

This most often comes down to either 1. doing more stuff on the backend or 2. struggling with ADO.NET and custom classes. Well, 1. we talked about and 2. also. Both are not ideal and have serious disadvantages in several ways as oposed to VFPs local DML. But I agree if you are not rely too much on these mechanisms, it might not be a big deal.

>I don't think any vendors will withdraw from the market as long as people are buying the controls. It doesn't cost them anyuthing to keep selling the existing controls.

>My point is that these controls are not likely to see any future enhancements. The vendor community is driven by sales - and ActiveX control sales are definitely on a hard decline. All you need to do is look at the commponent retail sites to see what they are putting front and center - it's not activeX controls. Those retails sites put up what sells so they can move product.

I'm not sure I agree with this. There still is an awfull lot done in activeX compatible languages. And not only .NET is ruling here. JAVA is also something that is more and more accepted by such vendors (eg. Crystal Reports).

>This reminds me of something a client I was doing training for told me once. He had an existing very complex Fox 2.x application. Ugly as all hell, with a cryptic user interface. BUt it was very, very fast. But scattered all over the place and nearly unmaintainable by anyone but the designer. The code was mostly pre Fox 2.x code, so there was no SQL Code anywhere - just SEEK, SEEK and SEEK again <g>... The code was next to unmanagable (even for this customer finding code was difficult). Yet he insisted that everytime he looked into using Rushmore and SELECT statements to clean up pages and pages of code, performance dropped considerably. While certainly there's some truth to this (using VFP commands is often faster than SELECT) most of the time the problem was using SQL Select incorrect, not properly optimizing for Rushmore or simply using SQL when the old code might have actually been more efficient. The gentleman went on raving about the DML in Visual FoxPro. Basically he ended
>migrating the application to VFP 7 just for hte UI, leaving the business logic usig basically the same pre 2.x code.

Well any way you put is SEEK, SCAN WHILE, etc is always going to perform better to process records than invoking rushmore with SQL Select. It is just because of the way rushmore and the SQL SELECT works. It is absolutely superiour in handling data in a record oriented way.

However when doing set oriented things like summarizing, grouping, relating to multiple tables in complex joins etc, for e.g. for report purposes, I definately would not go back to the 80's where you had long winded routines writing to temp tables doing all kinds of stuff to collect the data for your report. This is the area of the set oriented DML (SQL SELECT).

Depending on the applications GUI (grids, often don't lend itself well for filters, so you're better of with views, or use SET KEY), this clients application was build on fast technology. Whether it is maintainable and easy to upgrade when he needs to, is a total other question.

>Sometimes we look at our way of doing things as an excuse to not make changes that are necesasry or ignore other opportunities to expand the scope of our application or even as would be the case in this example, the maintenance of the application by reducing complexity.

Agreed. And sometimes we think that new technology totally replaces old ones. The SQL in VFP is not the solution to every problem. There are a lot of cases where good old xBase commands are far better suited to solve a particular problem than SQL, just because it is record oriented and SQL is not.

>I've done it, and I'm sure many of you reading this have done it. Heck, I probably am doing it today with some technologies like Java, or even worse in the past looking back and thinking of VB6.

Sure, we do it all the time. However, I tend to do this with tools quite more often than with development languages, just because the learning curve of that take too much time.

Walter,