Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Multiuser slow down
Message
De
26/12/2005 15:25:31
 
 
À
25/12/2005 07:43:12
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 8 SP1
OS:
Windows XP SP2
Network:
Windows 2003 Server
Database:
Visual FoxPro
Divers
Thread ID:
01080189
Message ID:
01080873
Vues:
17
Hi Jim,

that's the first thing I checked; unfortunately not.

Hank

>Hi Hank,
>
>Sounds like you may have an index on DELETED().
>If so, try removing it and see what you get.
>
>Good luck and Merry Christmas.
>
>
>>Hi Jon,
>>
>>what I've seen with FileMon (http://www.sysinternals.com/Utilities/Filemon.html) is (with the view expanded to include all commands, not just the default setting commands) that there is a QuickRead done by the file server for each and every record of the table being used in the query. Not that these take long: by definition the QuickRead does not take that long; but when it is 400K or more of the critters, it can take a while. When there is only one user, locking contention is not an issue, and the QuickRead is not needed. This is an SMB thing: put the file on the same machine as the app, and with multiple users or not, the problem goes away.
>>
>>It's enough to make one give up on using views (except our apps have to be able to run on multiple backends).
>>
>>Hank
>>
>>>I'm perplexed on why this code is slowing down and would love some help to determine why.
>>>
>>>When I run this local view query and only one user is running I get great sub-second speed. When two users are running I get 3 second plus speed after one of the users has run the same query and it stays that way until both users get out of the application.
>>>
>>>I have run the coverage profiler and determined this select to be the problem.
>>>
>>>The view originally was part of the DBC on the server, but I have moved it to be within the code and removed it from the DBC. As I understand it this should not have a locking problem.
>>>
>>>There are four tables (all within the DBC) and indexes exist for all fields referenced in the WHERE and JOIN.
>>>
>>>Here's the statement being used.
>>>
>>>SELECT Icpart.cupartid, ;
>>>    Icinvt.ylist, ;
>>>    Icprce.crectype, ;
>>>    Icprce.iicsizeid, ;
>>>    Icprce.csellunit, ;
>>>    Icprce.yunitprice, ;
>>>    Icinvt.iitemno, ;
>>>    Icinvt.citemid, ;
>>>    Icinvt.cdescrip, ;
>>>    Icinvt.ndecnum, ;
>>>    Icinvt.citemtype, ;
>>>    Icinvt.cmatrix, ;
>>>    Icinvt.cstkunit, ;
>>>    Icinvt.clocation, ;
>>>    Icinvt.cclass, ;
>>>    Icinvt.lresell, ;
>>>    Icinvt.lnotavailable, ;
>>>    Icimxt.imxtno, ;
>>>    Icimxt.nonhndshlf, ;
>>>    Icimxt.nonhndwhse ;
>>>  FROM ta700!icpart ;
>>>    LEFT JOIN ta700!icinvt ON Icpart.iitemno == Icinvt.iitemno ;
>>>    LEFT JOIN ta700!icimxt ON Icpart.iitemno == Icimxt.iitemno ;
>>>    LEFT JOIN ta700!icprce ON Icpart.iitemno == Icprce.iitemno ;
>>>    AND Icprce.crectype = This.cRecType  ;
>>>    AND Icprce.cSellUnit == Icpart.cSellUnit ;
>>>  WHERE Icpart.cidtype <> This.cIDType  ;
>>>    AND Icpart.cupartid = This.cUPartID INTO CURSOR v_ICPartLookUpCmb
>>>
>>>
>>>Any insight would be appreciated.
>>>
>>>Jon
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform