At 11:18 AM 1/14/2009 -0600, Stephen Russell wrote: >On Wed, Jan 14, 2009 at 10:55 AM, MB Software Solutions General >Account <[email protected]> wrote: > > Stephen Russell wrote: > >> This is why C/S is superior then xBase. Your server is asked for what > >> the client needs, instead of pushing the entire index file and usually > >> the entire dbf to the client for every little request. > > > > C'mon, Steve...many times it's been said (and proven, iirc, by some > > great devs) that it doesn't push the entire DBF to the client. FUD > comment. >---------------------------- > >please tell me how you can pull data out of thin air if the rows are >not present?
Steve, you've been proven full of BS regarding your VFP understanding before. Just accept it. We all know you certainly are not using it anymore. So there's no need for you to try to continue to espouse VFP functionality. The bottom line is that no, when you open a table the whole thing does not by default come across the wire. VFP does have a general buffering scheme and if the index is quite small, it may indeed all come across. If it's megabytes it does not. Opening a table over a LAN is generally sub-second regardless of table/index size. Of course, actually joining data between tables has big differences between in a C/S environment and a standard VFP environment. In the C/S approach the request is handled on the machine where the data resides and the data requested is returned. The processing resource is centralized and shared by all connections. In the standard VFP approach, the connecting machine does the processing, pulling data from the server. The processing resources are distributed and load on the central resource is minimal (but data traffic is increased to enable the connecting machines to do their logic). In extreme cases either way the C/S approach could be slower due to heavy load, or the VFP approach could be slower due to network congestion. Hmmm... maybe I see a problem. In your VFP career, if you only did things the "MS-recommended" way, you may think that you must use SQL to open a VFP table (aka Views in data environments of forms, etc). And maybe you limited yourself to using SQL for every data operation. So maybe you were thinking that SQL was constantly being invoked when working with VFP data. That is not the case. >I wonder if your indexes are poorly designed <big laugh here because >having a lot is not the answer> that the data engine is not doing a >table scan after your joins in the linking subsets / tables, let alone >how it decides what to filter on in your where clause. > >Because the table is local it rips through real fast. Uh... I'm embarrassed to have to tell a fellow-developer this... um, you TEST IT!!!! Those of us that have spent time looking at what actually goes on under the hood have a pretty high degree of confidence as to what the VFP data engine is doing, and will do under certain circumstances. >What does everybody know about sql joins from a VFP POV/ What is >actual and what is suggested, made up, to the extreme of pure bull? >Everyone here sees that M$ bought FP to pull index technology to SQL >Server. If that is so why are there real hard rules to what indexes >are consumed in a query, and that you don't get a bunch of indexes for >a single table like you think happens in VFP? First, SQL is SQL. It's a construct to access relational data using "SET" theory. If you're asking if VFP folks are too stupid to actually figure out ways to optimize SQL queries, I guess I'll have to disagree. Some of the worst SQL sytax (and results) I've ever seen come from MS-Certified blah blah blah SQL Server gurus. I believe insiders at MS are the ones that clarified reasons that MS bought FP (and I think it was to improve Access not SQL Server - of course both of which still need vast improving). And apparently, MS has recently messed up their own SQL Server indexes (or at least their optimizer) because a recent upgrade at a client site caused slowdowns of probably 20-30% across the board (worse in some cases). So perhaps you should pick up the phone and rail away at MS's apparent lack of understanding their own technology. I can't remember the exact details of Rushmoore index implementation - you could look that up for yourself. But I will say this, having fixed length records vastly simplifies index creation and maintenance. The fact that I've seen load times of 5 min in VFP vs 45 minutes in SQL server for the same data implies at least some issues regarding index capability (definitely not all, but some). I don't create a lot of indexes on my VFP tables. I try to use common sense relational theory to decide. Now, when I create my temporary cursors that users are banging away on (analysis or data entry) I will go crazy there (indexing the temporary cursor). I want things to happen in a blink of an eye for them while they're working. So if they've got a few thousand rows of data they're analyzing, and they want resorts different ways multiple times, quick report, etc, it's gotta happen before their heart beats twice. -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.
