At 08:54 AM 4/10/2008 -0500, Stephen Russell wrote: >On Wed, Apr 9, 2008 at 6:06 PM, Jeff Johnson <[EMAIL PROTECTED]> wrote: > > > VFP tables work for me because they don't require a server like MSSQL > > Server or PostGreSQL or even Advantage. I can't install any server or ... > > tables work fine, but tables over 30MB start to get unresponsive. > > Backing up the tables takes a considerable amount of time also. > > Splitting the tables seemed like a reasonable approach.
I'm coming in late to this thread, so I may have missed something. 30MB is nothing for VFP, even over a slow network. So there must be something else going on. If Views are used extensively, that could be a problem. Views are really nothing more than a SQL statement. Using a View executes the SQL query. So, if you put Views in data environments of Forms, you end up running a SQL Query when the form starts. And if you've got a "complicated" query (joining lots of tables for look up values, etc), it will get bad pretty quick. You may want to look at opening all "supporting" (or lookup tables) at the start of the application and leaving them open. Especially if they are often used in "JOINS" or look ups in other parts of the code. 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. For most of the systems I've implemented, I create temporary cursors and populate them with data using a mix of SQL and VFP (SEEK/SET RELATION) code (whichever proves to be faster). Of course for "1 record" data entry forms, a SCATTER.... works best (after you've SEEK()'ed to the desired record). We haven't spent a whole lot of time in optimizing because it was quite snappy on a 10Mbps network and we expected most to have 100Mbps at least. But we found out later that some sites were running it over a T1 connection (which is 1.5 Mbps I think). Some of those folks told us it was more responsive than their corporate DB systems that they query <shrug>. 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). 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. 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> >------------------------------------------ > >That sounds terrible. You have target at 30 megs of data and you need to >split for performance? Ask Charlie how to fix your design, because he has >boasted about large systems in use befoe. 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. ;-) -Charlie _______________________________________________ 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.
