Doug,

It seems that I again stand alone on this issue.

>>>Walter,
>>
>>>It's really the same way with FoxPro and SQL (or any other tool really). SQL IS the absolute best tool for the job in many cases.
>>
>>In many cases, it is, but still stands that I experience some cases where a xBase approach is better.

>Ok, use them then. Please give me a real life example that you have worked on, ok? I'll bet that I could, with a minimum of fuss make it far more scaleble and manageable by taking my approach. With the emphasis on manageability.

Same example I gave Ed, rauh.

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.


>Perhaps in your area of the world people do things on a much smaller scale than elsewhere. Or you've just decided to play in the puddle rather than swim in the ocean. That you CHOOSE to develop small applications is not a "proof" that that is the best approach - or the worst, or bad, good, so-so or anything else.

The large thing only burdens the xBase in some cases, like the described behaviour of a filtered grid. If Set filter is fully optimized there is no disadvantage in using them on larger tables, which lead to the argument of larger DB sizes. In fact many xBase constructs do scale very well. I don't see that I should use a pure SQL approach for large VFP apps. It simply does not make any sense to me. There are lots of cases where xBase equivalent which blow the hell out of SQL equivalent. I gave an example of browsing trough a cartesian product table which is fairly easy within VFP, but never finishes within SQL. the SQL SELECT command has the disadvantage that it creates a (temp) table whereas xBase work trough the original tables. If you deeply think of this distinction you might discover for yourself that there are advantages to xBase commands in some cases.

Again let me say clear. Of course in a awfull lot of cases SQL pays of nicely, but in some cases you might better look for xBase equivalents. Just saying that a pure SQL appraoch is the way to go is a proof of ignorance.

>When it comes to managing 1,000,000+ records, which is if I recall the general presumption here, I can more often than not get better results for my customer by using a SQL backend than using SET FILTER. Goodnees, those two ideas aren't even in the same league.

Here you say it yourself: often. Which implies that there are cases where SET FILTER is the better choice. I'm just saying this, not more, not less.

>Look, there are some VERY bright people who are attempting to help you here.

I don't need help. I've got a opinion. I've no problem with performance issues nor scalability. My applications are highly custom made, giving the best from VFP. Sometimes I use SQL, sometimes I use xBase command, depending on the most logical situation. I've got an opinion that I'm right and the others are wrong, just like i did with the index on DELETED() tag. I do not follow the general opinion of the VFP GURU, I make my own.

>At least I know I can trounce you if I ever compete for business against you. *g*

Don't be too sure about this. You never saw an application of me.

>>Might be, but small databases also are. I've got lot's of clients which manage relatively small databases where a xBase approach sometimes is the best.

>Fine. I have absolutely no trouble that you prefer to fight for the bottom rung of the ladder Walter.

I've got 5 different applications running at about 20 sites for Justice (Government) which handle fairly small amounts of data. I would not call this the bottom rang of the ladder.

>However, I'd echo Ed Rauh and Jim Booth and state that you are limiting yourself in your own mind. Like them I just hate to see it happen. It's unnecessary.

On the contrary, I find their view limiting. Im using both strategies: SQL and xBase and use the one which is best. Only using SQL because of it is more modern is limiting from my POV.

Walter,