Ed,

>>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 stand corrected on this.

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

On the contruary, ed , you've missed the point. The point is that SET FILTER can be of any value depending on the situation. Low selectivity in large tables in a grid is not one of them. For other cases there should be no objection for SET FILTER.


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

No I don't, people who have both of them have an advantage of getting the most out of VFP. Both people who solely depend on either xBase or SQL have an disadvantage.

>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

This arguments does not make sense too me. Im fully aware of the advantages of SQL and xBase constructs. Unlike you seems to know, I know the main difference between the two. Maybe you don't want to see the difference.

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

If you read my messages carefully, you'll see, I never said that xBase is the way to go. I've only stated that there are cases where xBase commands pay off. Therefore I see cases where SET FILTER is handy.

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

Again, I'm fully aware of any SQL capability within VFP and beyond. But I'm willing to see circumstances where xBase pay off:

example:
USE sometable
SET FILTER TO &cFilter

REPORT FORM (cReport) TO PRINTER PROMPT

Compare this with:

SELECT * FROM sometable WHERE &cFilter INTO CURSOR Cursor

REPORT FORM (cReport) TO PRINTER PROMPT

Lets say that the SQL select command takes 2 minutes and the report form 3 minutes. Both approaches take 5 minutes on the whole. In which case do you think the pages are printed in the fasted way (given that the printer will begin printing after the first page is spooled) ?

It becomes even more clear when the user only want to print the first page.

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

Again ed, you missed the point. asyncronous queries complete the query even when you don't need the rest of the result. If you do a browse of a table, it only requests the rest of the table when the rest of the table is adressed. This is clearly a batched behaviour.

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

They don't have to scale. If they've had to scale I would have developed them to scale. Clearly you don't understand that much of VFP development doesn't scale. Do you use comboboxes in your forms based on tables ? Maybe you don't, but whole tribes do use them. If you have the knowledge that there will be only about 50 states in america. would you take the steps to take care of a situation where there exist 5,000 states ? I don't think so. If you do, I think you fail on developing an effective UI.

>>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 comes in many forms, I was talking about C/S in a server RDBMS way.

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

VFP and VDBASE still exists, so the xBase standard is still evolving.

>SQL is not solely an RDBMS technology

I never denied this.

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

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

If you read more carefully to what i'm saying you might conclude otherwise. Clearly you're opiniated against me, and don't want to closely follow the words i'm saying therefore debateing with you seems pointless. You clearly don't even want to hear what I say, and scream and object in advance.

EOT.

Walter,