Ed,

>Walter, any business that sends out palette sized or larger shipments needs at least the rates from their point of shipment to other locations in the continental United States, and if they contract their inbound freight, from all points to their location .....

I agree that in this curcumstances you might look for another strategy. Using p-views within the current technologies are probably the best way to do this. For the future I see much improvements in terms of using aggregated views just in the way we look at constructs that can be accomplished with xBase command.

Like you do, I want to get rid of some xBase commands (though they should be available for backward compatability), but at this moment I feel I can't do the things I want to do with SQL. IMO this is exactly why xBase still exists today. If you know what you're doing you can achieve more performance and flexibility with xBase command.

I also like the SQL's 'only spicifying what you want strategy' rather than the 'implement it your way' phylosophy, but like comparing comparing a 3rd generation with a 4th generation language the 3rd generation language provides more flexibility than the 4th. Therefore I'm just waiting for a new SQL standard which provide enough flexibility and power to replace the xBase commands.

for example, wouldn't be nice that if I want to use a view which logically contains several hundred of thousands of records the server returns only the first needed records and provides the rest on request, just like it works with pure xBase tables ? This won't burden the server with a load of queries whereof the most is not used by the frontend. I agree you can do this already with batched SQL-queries to some extend, but there is need to do this automaticly and transparent for the user and developer.

>How much spam do you get each week offering millions of email addresses for a small fee? I probably see a half-dozen a week - and that's with Outlook dropping the obvious ones off into the bit bucket without my ever seeing them. And where do you think all those twits got your email address? And how do they manage them? Hmmmm...

I think we are in total different markets here. My applications are mainly ment for database sizes which do not exeed the 100 Mb limit. I really doubt that the majority of VFP applications deal with more than that. I truly believe you must use C/S technologie, how immature it still is: it is the best way to accomplish this. VFP can provide a front-end and/or middletier and use some limited datahandeling on the DBMS side. Of course this depends on more than only just the DB size.

>My perspective here is that I like having tools that take advantage of otherwise idle cycles to analyse the history of user requests and try to. It's inevitable that given a system that is not overburdened, there will some useful and usable idle time available to expend on lower priority tasks that can be performed in part or whole asynchronously in anticipation of future user requirements. If you guess wrong about what will be needed in the future, you're no worse off than if the system just sat there and twiddled its thumbs.

I think their is still lot's of room for improvements of RDBMSs, and I truly believe that they will show some features already accomplishable within xBase (VFP) in the near future. An example of one feature implemented some time ago in SQL-server is the handling of server-side cursors which provide some record based mechanisms.

Until, RDBMS provide the same technology as xBase languages, I'll be forced to use commands like SET FILTER, SET RELEATION etc..

Walter,