Charlie Coleman wrote: > <snipped> > Next, if direct table access is being used you might be getting bit by SET > FILTER statements. I don't think I can offer much help here. Direct table > access should really only be used in very specific circumstances. If it's > throughout the code, it'd be tough to pull it out. >
If one can learn to design without direct table access, then I'd say the major part of your battle is won when coming to grips with development in a C/S style. > <snipped> But you mentioned > a 256k network line (I think).... I don't think anyone I've dealt with used > something that slow - other than dialing up into Citrix, etc (which worked > fine of course). > Yeah, that does suck for you JJ. Their problem with technology becomes your problem....crap! > The last thing I can think of is considering the VFP indexes. When a table > (NOT a View) is opened (USE'd), VFP brings down "part" of the index. I > think if that index file is huge "opening" performance could be affected. > So maybe look at the indexes and see if there are any keys that aren't > really used - e.g. indexes on big strings. I've seen people create those so > that it'd be quick to view the data in a different 'sort' order - but since > you can build an index on a temporary cursor, it's generally better to not > have those type indexes and just build the sorting/indexing on the fly. > Excellent point. I think indexes for the purposes of display order should be discouraged when possible for this very reason. > A final recommendation would be to post "messages" to the users during the > "long" delays you are seeing. In some cases you may not be able to (e.g. > when you execute the USE, you see a 10 minute delay.... can't really hook > into that I don't think). But if you're doing SCANS to save data, or even > using SQL to extract data, you can call a function to show progress - or > just that activity is still occurring. This may even give you more > information later to track down issues. And the users may see that all that > streaming audio at lunch is having an effect on their work performance. <g> > Another good one. This is standard "good UI design" -- communications back to the user when a process may take some time. <snipped> > Why thanks Steve. I actually ought to apologize because I don't want it to > come across as boasting. I send out that my info to counteract > misinformation (deliberate or accidental) and other incorrect assumptions. > The computer industry is full of flat-out bullcrap nowadays. It's a real > shame too since billions of dollars are being wasted - saps our GDP - saps > our ability to actually advance technology. > Nowadays? I think it's been like that for YEARS. Uber-geeks who obfuscate too much in order for their own nerdy superiority and/or for their own job security. _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
