Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Progress /Record Count during index
- Thread starter andy0923
- Start date
Griff,
Agree... I have found this on many occasions, especially when working with record sets in the millions, and I want a very small scope, say 200 - 300 max. Especially if you have "escape clauses" for certain conditions... but it's all about using the "Right tool for the job". I use this only sometimes.
Best Regards,
Scott
"Everything should be made as simple as possible, and no simpler."![[hammer]](/data/assets/smilies/hammer.gif "[hammer] [hammer]")
Agree... I have found this on many occasions, especially when working with record sets in the millions, and I want a very small scope, say 200 - 300 max. Especially if you have "escape clauses" for certain conditions... but it's all about using the "Right tool for the job". I use this only sometimes.
Best Regards,
Scott
"Everything should be made as simple as possible, and no simpler."
Hi Baltman,
It was for a question on here a while ago, someone wanted to know how to do something - I don't remember what now - and about three or four of us set up some simple tests to show how to extract the info.
Scan/EndScan came out slower on very large record sets, I can't even remember which ones or what the test was for... old age kicking in! I *AM* pretty sure the test conditions will have been field specific though - not based on a UDF test.
Regards
Griff
Keep [Smile]ing
It was for a question on here a while ago, someone wanted to know how to do something - I don't remember what now - and about three or four of us set up some simple tests to show how to extract the info.
Scan/EndScan came out slower on very large record sets, I can't even remember which ones or what the test was for... old age kicking in! I *AM* pretty sure the test conditions will have been field specific though - not based on a UDF test.
Regards
Griff
Keep [Smile]ing
Well, the speed of the SCAN/ENDSCAN would have been holy dependant upon a matching index... no matching index, it would be VERY slow on a large record set... but then almost everything is in that case.
Best Regards,
Scott
"Everything should be made as simple as possible, and no simpler."
Best Regards,
Scott
"Everything should be made as simple as possible, and no simpler."
I'm pretty sure the test was for say processing 200000 records using an index on a table with 20 million or somesuch - and the 'hard coded' *do while* worked out measurably faster than the similarly coded *scan* technique... but a search on Tek-Tips doesn't bring up anything that matches that, so perhaps I'm dreaming B-)
Regards
Griff
Keep [Smile]ing
Regards
Griff
Keep [Smile]ing
Hi Mike,
I'me sure your point is valid - I can't say as I haven't tested it, and am happy using a 'designed' approach with indexes.
The Scan/EndScan thing I'm sure was on Tek-Tips, and I've just about convinced myself that the Do While/EndDo came out measureably faster on large record sets - but the search features on Tek-Tips won't help me find it!
B-)
Regards
Griff
Keep [Smile]ing
I'me sure your point is valid - I can't say as I haven't tested it, and am happy using a 'designed' approach with indexes.
The Scan/EndScan thing I'm sure was on Tek-Tips, and I've just about convinced myself that the Do While/EndDo came out measureably faster on large record sets - but the search features on Tek-Tips won't help me find it!
B-)
Regards
Griff
Keep [Smile]ing
TamarGranor
Programmer
It's been a while, but I tested DO WHILE against SCAN for HackFox. Here's what I had to say:
Guess what? DO WHILE isn't the best choice for looping through records either. SCAN was designed to process a table efficiently and does it faster than DO WHILE. Our results show that SCAN is one-and-a-half to two times faster to simply go through an unordered table one record at a time.
To give full disclosure, we have found that with some index orders, DO WHILE was as much as 20 percent faster. With other indexes, SCAN is faster, although it doesn't appear to have the same advantage as in an unordered table. (It's also worth noting that, with large tables, if the memory allocation to FoxPro isn't property tuned—see below—DO WHILE can be faster than SCAN.)
Tamar
Guess what? DO WHILE isn't the best choice for looping through records either. SCAN was designed to process a table efficiently and does it faster than DO WHILE. Our results show that SCAN is one-and-a-half to two times faster to simply go through an unordered table one record at a time.
To give full disclosure, we have found that with some index orders, DO WHILE was as much as 20 percent faster. With other indexes, SCAN is faster, although it doesn't appear to have the same advantage as in an unordered table. (It's also worth noting that, with large tables, if the memory allocation to FoxPro isn't property tuned—see below—DO WHILE can be faster than SCAN.)
Tamar
I couldn't find the original Tek-tips topic, so I created a table with 100K records randomly inside 1.1Mln records and then did the scan/endscan and do while/enddo on it, using a seek to locate the first record and then letting VFP do the rest, twice:
The results are... exactly the same!
3 secs for each
So, I am probably wrong (and right) and do while is just as quick, no slower than scan
Interesting?
Regards
Griff
Keep [Smile]ing
The results are... exactly the same!
3 secs for each
So, I am probably wrong (and right) and do while is just as quick, no slower than scan
Interesting?
Regards
Griff
Keep [Smile]ing
Olaf Doschke
Programmer
Hi Griff,
you should extend the case: within the while loop select onather alias, then select the main alias you loop through before the skip again. Scan Endscan does not need the scenned alias being selected, it does so automatically.
Besiedes scanning one table only is often not enough. I once thought like you, but SQL has great advantages over xbase, when it get's more complicated.
Bye, Olaf.
you should extend the case: within the while loop select onather alias, then select the main alias you loop through before the skip again. Scan Endscan does not need the scenned alias being selected, it does so automatically.
Besiedes scanning one table only is often not enough. I once thought like you, but SQL has great advantages over xbase, when it get's more complicated.
Bye, Olaf.
- Status
