Raphael, I worded it badly I'm afraid and I'm sure you know what I meant anyway!
SQL statements will optimize themselves simply by having details on the indexes available. i.e they will work out the records required from the cdx's structure(s) and having got a list of the record pointers required, only upload from the table store the records that satisfy the SQL statement (where clause). Hence the need to optimize the index structure so that Rushmore actually works. Have you looked at the Rushmore output sys(3054,...) to see if the queries are optimized? After all a cursor adapter is only a SPT request wrapped up in a pretty wrapper. Simply issuing a select * with no where clause will upload all the table data regardless, unlike native VFP where only the first records required for display are uploaded. You are obviously aware of the various parameters available in cursorsetprop() that can also limit the mount of data transferred when using network topology e.g. FetchAsNeeded and FetchSize etc... Dave -----Original Message----- From: ProFox [mailto:[email protected]] On Behalf Of Rafael Copquin Sent: 10 July 2014 13:31 To: [email protected] Subject: Re: issue with dbf's To begin with, I have been using CA's extensively for years, especially with SQL Server as a back end, with no problems whatsoever. And then, a lot less work in coding when you have to edit data. But the second part of your memo ("SQL that has to download part or all of the table and not just the index....etc") is confusing to me. Could you please expand? Rafael Copquin El 09/07/2014 12:24, Dave Crozier escribió: > Raphael, > Why exactly do you want to use a CA? If it is because you don't want to > convert the old tables to VFP9 format then I'd seriously look at biting the > bullet - unless of course that means lots more work. > > CA's do generate SQL that has to download part or all of the table and not > just the index especially when you do a select *. Can you not just select the > data fields you need then when a record is selected pull back ALL the data > for the PK of that record? > > What are your CA parameters? > > Dave > > > -----Original Message----- > From: ProFox [mailto:[email protected]] On Behalf Of Rafael > Copquin > Sent: 09 July 2014 16:21 > To: [email protected] > Subject: issue with dbf's > > I am migrating an old DOS app to VFP 9. The client does not even want > to hear about SQL Server or any flavour of an outside engine > (MYSQL,MSSQL,etc) > > The DOS program uses several tables that have hundreds of thousands of > records and they use the application in a LAN > > If I use the tables as the old FOX DOS does, namely, open the table and > navigate it with the arrow keys or the pageup, pagedown, end,top keys, the > screens fly. > > There is this table that has over a million records. I want to use a > cursor adapter to do handle it, but find that the sql command takes > over > 5 seconds to open the table. > > I figured I would use a pagination scheme, that is, select 100 records at a > time with the cursor adapter, let the user edit any records they want, and > then select another batch of 100 records. Use the page up, page down keys, > etc to select batches of records. But every time I issue the select > statement, it takes about 5 seconds to bring the record set. > > The table has a primary key, which is used by the cursor adapter. If I do not > use a CA and simply use a SQL statement, the delay is the same. > > And we are talking my developing machine (single user) > > There are no Rushmore issues here, as far as I can tell, because I only have > the PK index and the select statement just uses commands like: > > select top 100 * from thetable order by pk asc > > select top 100 * from the table where pk > 100 order by pk asc > > etc > > Why would it take so long to select the records, if the table is sitting in > my own HD? > > I fear to think what it will do if the table is in a LAN server. > > Rafael Copquin > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.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.
