On Wed, Jan 14, 2009 at 3:46 PM, MB Software Solutions General Account <[email protected]> wrote: > Paul McNett wrote: >> Jean Laeremans wrote: >>> Oh forgot to mention took the time to find the most effective >>> retrieval technique and found out that in general xbase commands were >>> several factors faster than SQL. >> >> I don't think anyone is contesting this. xbase processes on a LAN really > do fly. >> >> I'm with Stephen, though: there are many compelling reasons to move up > to a C/S >> architecture. > > > I haven't designed anything brand new with a VFP backend since about > 2004, iirc. I've been using MySQL, and for many reasons, I love it > (especially the ability to be disconnected for a time--avoiding the > Error 1104s of the past with flakely networks using VFP backends on a > LAN). FabMate still uses VFP9, and it still kicks ass, but I'd love to > rewrite it with a MySQL backend for many reasons--disconnected > advantage, running on server for intense processes (and this is perhaps > where Steve was eluding), Web database ability, and probably more. But > where he made his mistake which the others rammed him for was his > comment that the entire table comes down across the network. Nope. --------------------------
Past your WAG, or repeating others, can you prove that it does not? I mean actual factual web proff. Because without anything that states different it has to pull down to local for data that is used, presented. Sorry but you have to get that description of Stock or that customers address from somewhere. Now to push it to the extreme how do you think that it can pull down indi rows of data instead of chucks of rows? So as pointers are moving and hitting a variety of rows across the TABLE and your changing the index how does it NOT PULL all that data local? We put extremes out of bounds and say I have a 1.5 gig table and it never comes all down. that may be on transactions that are out of scope for a date range, say 2008 rows are only 15% of the volume of the table. Now take into consideration your customer table that is liked to that mega order/details table(s) that is brought down. You may have only received reportin on your clients with outstanding invoices (40% today) but I bet that the entire table is now local instead of the the few you were interested in. So to look back at the 1.5 gig table if your doing forecasting then I bet that whole table is coming down. To restate the obvious, USE myTable starts the index down. Brow you see some data. Go bott does not bring the entire table at that point, just allowed to see it. But put a sniffer on your network and you will see a ton of bits coming your way! Skip -100 a few times and it is amazing how much traffic your doing. OK, lets really have fun. use use myBigTable Exclu reindex I know how much that use to abuse the network when my network admin came into my office to see what I was doing. Still a good friend now located in Dallas. But he was amazed at how I could spike the traffic with that little command. So can you find proof to your accusations that my statements are false? I have to study these same things in refactoring projects all the time. It doesn't matter what the back end is, these same types of rules are in effect. VFP is not shielded, it just has that gloss overlay that you think it it cool. FP / VFP ahead of AJAX by more than 15 years. > In my time using VFP as a backend in designs that I've created, I'm > thankful to say that I've never had any corruption. I know I've worked > on others systems where there was corruption, and if it were to be > redone, I would definitely take a different approach than some of the > earlier designs, but all in all, I'd recommend using MySQL as the > backend, given my success so far with it. I'd love to try out > PostgreSQL and Firebird as well, and given my n-tier designs, I bet I > could do so without much change in code. I just need to invent more > time first....or get rid of all my debts so I had more ability to create > free time. ;-) > > > > > > [excessive quoting removed by server] _______________________________________________ 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.
