Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
SCAN is too slow
Message
From
13/06/2002 22:14:05
 
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00668312
Message ID:
00668344
Views:
31
This'll be faster, guaranteed. Note the *[sb] and && comments. Your pseudocode is preserved.
* sele tabela A 
* set order to indice 
sele tabela B 
* go top 
scan   && SCAN has implicit GO TOP
  * sele tabela A 
  * seek(tabela B.campo) 
  * if found() 
  IF seek(tabela B.campo, tabela A, indice) && SEEK() function
    *[sb] < 1 >
    *[sb] < 2 >
    replace value from tabelaB to tabelaA 
    *[sb] < /2 >
    * sele tabela B 
    *[sb] < /1 >
    *[sb] < 3/ >
  endif 
endscan   && ENDSCAN always does implicit table select
If indece is not unique, you may have an additional optimization by adding a SCAN WHILE where I've placed the < 1 > tag, especially if indece has large clusters of distinct values.

If tabela B.campo is not unique and is the active index, you may benefit from an empty SCAN WHILE to the next distinct value at tag < 3 >. Similarly if tabela B.campo is not unique, consider running the outer SCAN off a SELECT DISTINCT ... FROM Tabela B cursor if you've got great clusters of tabela B.campo values.

If you expect many redundant REPLACE statements, you might benefit from an IF ... <> ... test at tag < 2 >

An UPDATE SQL might be faster, but smart procedural code is often as fast or faster in VFP.

If you expect to do this regularly, you will definitely benefit by having the tabela A physically sorted on the sought key, and this will probably be most helpful if you use UPDATE SQL.

If you're just updating missing values, and not refreshing existing records, consider a SELECT DISTINCT Foo FROM tabela A WHERE NOT IN (SELECT Foo FROM tabela B) and making the resultant cursor the object of the outer SCAN
On a table this size, you will benefite from SET EXCLUSIVE ON if you can manage that, and you *might* benefit from table buffering.

As usual in these matters, I'm guessing, and it depends on the specifics of your case. Surely other optimizations are worth considering.

Note that you're in a SQL Server sweet-spot here...

**--** Steve



>I friend of mine did a program as below and complains
>scan is too low.
>He as 3,000,000 records
>He wonder if the struct is correct or is there a better way
>to do that.
>Tables are into a database
>
>sele tabela A
>set order to indice
>sele tabela B
>go top
>scan
>sele tabela A
>seek(tabela B.campo)
>if found()
>replace value from tabelaB to tabelaA
>sele tabela B
>endif
>endscan
Previous
Reply
Map
View

Click here to load this message in the networking platform