Damn Ed,

This post I just had to throw in my Save Folder. ;>)


>I'm prefixing this message with a clear warning; people who don't want my opinion can stop reading now. This message does not deal with abstract arguments; it's not a debate. It does point out how you attempt to squirm when confronted with the reality of the world around you. It is a pure critique of invalid statements. It's not an invitation to theoretical discussion. I'm tired of listening to your attemtped portrayal of the evils of SQL technology and techniques, and your misguided and fervent advent of xBASE as the savior of application development. There is no need to respond to these points. I don't want to waste my time and others' bandwidth on the befuddled dissemblings of a misguided and misinformed mind.
>
>>>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.
>>
>
>Walter, you've suceeded in missing the issue being demonstrated, that being the size of data needed for businesses to adequately address their operational needs. You've stated that any business with large data requirements is not a "small to mid-sized" business. I gave these specific examples as typical small to mid-sized businesses, representative of the business marketplace as a whole, that do have a need for large data volumes. Your attempt to redirect the issue to "well, in this circumstance, I'd look for another strategy" is an attempt to avoid the issue. Small and mid-sized businesses often have large volume data requirements, in many typical situations, and no amount of waffling will avoid this fact. You misrepresent data requirements as associated with the size of the operation, not the operational requirements of doing busienss effectively. Your analysis is inherently flawed.
>
>>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.
>
>Walter, I think I do know what I'm doing, and I've given scenarios where you admit that an xBASE approach to dealing with these situations is non-optimal, and perhaps even inappropriate. You imply that people who rely on SQL technolgically have less skill than you. I'd argue instead that you're terrified of having to deal with an unfamiliar development environment and will attempt to make any excuse to avoid learning how the job can be done better. I'd state that people who have learned to make use of the SQL technologies because of the advantages that can be gained from them "know what they're doing", and foolishly arguing that continuing to rely on procedural, non-adaptive and unscalable, but familiar, paradigms, and attempting to make ad-hominem arguments that "people in the know" don't rely on such weak techniques is a sign of ineptitude at best, and incompetence at worst. At a minimum, it shows a lack of understanding of the capabilities provided through the SQL
>virtualization of the data engine.
>
>>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.
>
>At which point, you'll state that the new language constructs are flawed and limiting, and that good old xBASE is the "only" right approach. SQL constructs can "implement things using processes as specified" in a query; as an example of this approach, look at the FORCE clause of the SELECT statement sometime. Don't complain about things being too limited when you don't understand what they can achieve.
>
>>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.
>>
>
>Walter, you've clearly not worked with a backend; you can control the size of data moved from the server, and the client can do things in parallel with the server's continued processing. xBASE command can't - everything must be finished before another, perhaps paralell and disjoint, operation can proceed. This isn't something that requires "batched SQL queries", this is true asynchronous operation, with the client application having the ability to either proceed or pause and waiting on reported completion of the operation. Asynchronous processing is not an option in monolithic single-tier, single threaded environment. The xBASE constructs do not offer this as an option as a native capacity.
>
>>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.
>
>The truth comes out. Your apps don't scale.
>
>>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.
>>
>
>Walter, here you demonstrate that you don't understand what client-server technology is. Every one of us operating in a network environment has a reliance on client-server technology. Every one of use who relies on the service of one application to meet the needs of another makes use of the client-server paradigm, every damned day of our existance. If client-server were more than a buzzword to you, you'd realize this.
>
>Client-server paradigms exist in more than the database backend environment.
>
>Yes, I use client-server technology. And I know when and where it's appropriate.
>
>>>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.
>>
>
>I don't argue that database technology is fully developed, but it is not stagnant. xBASE and procedural language constructs OTOH are. SQL is not solely an RDBMS technology; in fact, it serves to virtualize the underlying mechanisms used to store and retrieve data. SQL can and is applied equally well to services provided by tools that rely on other data models (IMS, for example, is a hierarchical model backend that has a SQL interface available; ObjectStore is a pure OODBMS that is closest to a network model implementation, and it, too, supports SQL operations.) Utilizing SQL allows the data manipulation technology to grow and change without having to radically alter the approach to data manipulation; xBASE is inherently reliant on explicit index-based operations, and is incapable of adaptive behavior without programmer intervention.
>
>I'll reserve judgments on the immaturity of the technology until someone with greater experience with and understanding of the theoretical and actual capacities makes a statement. You don't meet the requirement. To use a bit of street slang, you don't walk the walk, and can't even talk the talk.
>
>>Until, RDBMS provide the same technology as xBase languages, I'll be forced to use commands like SET FILTER, SET RELEATION etc..
>
>Don't let me stop you, just don't misrepresent yourself as having the expertise to know when and how the technology and capabilities are present.