access faster a dbc in an intranet

[lennax]

<b>Well i'm working in a company who has a sistem spread into an intranet and every day each node access the dbc which is in the server, but when they do this (i mean access and filter the tables from a dbc) this take several minutes, does someone know how to avoid this? i would really aprecciate some help. </b><br>Thank you¡¡<br>

 

[79251]

Hi Lennax,<br><br>Can you tell me how they are accessing.&nbsp;&nbsp;Whether it is thin client or front developed using visual foxpro.<br><br>If you are using DCOM objects to acccess your database this may very slow.&nbsp;&nbsp;<br><br>If you are using visual foxpro front end try sharing that server's Database directory then use in your application this may faster.<br><br>If you are using any combo box for a huge table this may also be slow down your form.<br><br>Dont' use SET FILTER TO&nbsp;&nbsp;command any where in your application, instead you can use SELECT SQL QUERY into a table.<br><br>These are all the practical problems I faced.<br><br>Hope one of the solution will solve your&nbsp;&nbsp;problem.<br><br>Logamoorthy

 

[foxdev]

More questions:<br>&nbsp;&nbsp;&nbsp;&nbsp;Is it a program that is accessing the DBCs?<br>&nbsp;&nbsp;&nbsp;&nbsp;Are the DBCs used to access remote data (not DBFs)?<br><br>If the answer to both is yes, you can create a small routine to run at program startup that copies the DBCs to each user's local Temp directory; it could check the timestamps on the files and only copy them if they are the same.<br><br>If you are primarily using shared DBFs (not remote data), then this approach won't work for you. <p>Robert Bradley<br><a href=mailto: > </a><br><a href=

http://www.foxdev.com/>FoxDev

- Visual FoxPro Development</a><br>

 

[JDurbin]

The filter has got to be killing him.&nbsp;&nbsp;Use SQL or paremetized views.&nbsp;&nbsp;That's where I'd start <p>John Durbin<br><a href=mailto: > </a><br><a href= > </a><br>ICQ VFP ActiveList #73897253

 

[Steve Bowman]

Might just need an index to match the filter, under the circumstance this might speed up the filtering process without rewriting the app to use SQL cursors, Views ... there are many ways to do this right, but sometimes that is just not the possiable. I remember in the old days pre version 2 setting a filter was about the only way to seggregate a subset of data. The problem was under development working with small amounts of data most filter routienes worked fairly fast, now years later after the data has grown to many megabites it just don't work I test all apps with a larger then expected database I wrote a small program that builds a DBF of the needed size and stru and populates it with data so there are no suprizes later. <p>Steve Bowman<br><a href=mailto:steve.bowman@wayservices.com>steve.bowman@wayservices.com</a><br><a href= > </a><br>