I got you now
Thank you
Rafael
El 10/07/2014 9:45, Dave Crozier escribió:
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.
