Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Very slow SQL Update even when index exists
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Versions des environnements
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP2
Network:
Windows 2000 Server
Database:
Visual FoxPro
Divers
Thread ID:
01174680
Message ID:
01174730
Vues:
10
>>>>
>>>>The result of SYS(3054)is:
>>>>
&mSqlCommand
>>>>Rushmore optimization level for intermediate result: none
>>>>Rushmore optimization level for table ivinvt: none
>>>>Joining table ivinvt and intermediate result using temp index
>>>>
>>>>Good suggestion but I don't know why it is not using Rushmore.
>>>>
>>>>Thanks for the help.
>>>
>>Did you have ORDER by K_Ivinvt of Ivinvt table?
>>- YES
>>
>>Did ivinvt.k_ivinvt AND c_chng.k_ivinvt have the same length (if they are strings)?
>>- Same Size
>>
>>What is SET DELETED status (WAIT WINDOW SET{DELETED]))?
>>- SET DELETED is ON
>
>What type is K_Ivinvt?
>If K_Ivinvt is some kind of numeric try:
>
>SYS(3054,12,[TestMe])
>UPDATE.....
>WHERE K_Ivinvt = 1
>MessageBox(TestMe)
>
>and tell me the result.


I moved the SQL to a stand alone prg with only the sql in it. The cursor c_chng is now a tabel with one record.

If I use this code it runs in .01 seconds:
update ivinvt ;
 set allocated = allocated + c_chng.chng ;
 from ivinvt ;
   join c_chng 
    on c_chng.k_ivinvt = ivinvt.k_ivinvt ;
    where ivinvt.k_ivinvt = 'AQOPO'
If I change the last line to this it take 12-15 seconds
where ivinvt.k_ivinvt in (select k_ivinvt from c_chng)
Beer is proof that God loves man, and wants him to be happy. - Benjamin Franklin
John J. Henn
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform