<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>
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
access faster a dbc in an intranet
- Thread starter lennax
- Start date
Hi Lennax,<br><br>Can you tell me how they are accessing. 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. <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 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 problem.<br><br>Logamoorthy
More questions:<br> Is it a program that is accessing the DBCs?<br> 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= - Visual FoxPro Development</a><br>
Steve Bowman
MIS
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>
- Status
Similar threads
- Question