On Wed, Jan 14, 2009 at 1:09 PM, Charlie Coleman <[email protected]> wrote: > 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. ------------------------
I have an estimate to finish on another app toady so I cant get into this with a great deal of time. But opening at table is smoke and mirrors, using it's data is the only aspect I care about. Having a form that is for customer maintenance may require 5 to 15 tables for all data needed for company, contacts, types of business, States , Countries, Sales Reps., .... Once you start to request the data from the tables that is how you get the dbf loaded locally. It is not the first opening, but the use of the open tables. Move those record pointers around and you get your data locally. If your using SQL in putting data together for a grid to show descriptions of FKeyed data tables your moving pointers around a great deal. If you don't and you just relate tables to one another as those pointers move that data is coming your way for possibly a report. Down to what is going on under the hood with respect to data and the engine. My comments are only in SQL syntax based operations. I use SQL 99% of the time. I have found that loading data into SQL Server taking 45 min? What were you loading 25 gig of starting text data? Or was that using the Upsizer from M$? From a SQL Server standpoint I can load up individual tables of data very fast, seconds for 100,000 row tables. A db that will be in the 10 gig size where data is dispersed between many different environments? Probably get that done in a 3-10 min job using old DTS for SQL2000 or it's replacement in 2005. Funny how I have not witnessed the index problem you are talking about of increases in a %? are you talking about load times, CURD speed in general or getting your statistics? I found this <https://forums.microsoft.com/Forums/ShowPost.aspx?PostID=3585304&SiteID=1&pageid=0> as the only thing that looked like what your comment might be based upon? So little there just a WAG. My goole q was "SQL Server upgrade slowdown" Funny but I didn't see any reference to any types of people who have had problems where their data was now much slower? Some people were complaining on how fast upgrades come up. But nobody else has your issue and is pissed off enough to start threads, blogs, etc. So you blowing smoke again or are you reacting like a PHB? > 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 > > > > [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.
