Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
SCAN is too slow
Message
De
13/06/2002 22:14:05
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Divers
Thread ID:
00668312
Message ID:
00668344
Vues:
30
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
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform