A) You said the SQL statement is fast. If it is, is undoubtely making use
of one of the CDX entries. If so...
Tell me if this can help. Suppose your browse statement is something like
this:
BROWSE FIELDS field1,field2,...,field3;
TITLE "MyWindowTitle";
NOWAIT;
FOR Index_key = m.condition...
In spite the order is set to zero, the Rushmore is always active unless you
SET OPTIMIZE OFF. Keep in mind the *only* condition to be fullfilled is the
<index_key> must match exactly at least one key in the CDX entries.You can
even set order to another key entry in the CDX, Rushmore will continue
filtering the BROWSE data respecting the FOR clause explicity stated in the
command shown above.
When you want to refresh the window, change the <m.condition> varmem
contents, and issue inmediately
SHOW WINDOW "MyWindowTitle" REFRESH
to update the browse window. The data is updated very quick. Perhaps only
the last record of the new recordset that match the new condition appears
then in the browse window. To fix it, you can locate the first record of
the new recordset by issuing:
SET ORDER TO Tag_Name && set order to perform a seek
=SEEK(m.condition) && locate the first record that match the new
condition
SET ORDER TO 0 && reset to zero order
SHOW WINDOW "MyWindowTitle" REFRESH && refresh
I use this technique in a table with 58.000 records of 0.7Kbytes width each
in a 10MBPS ethernet, and it works with very acceptable speed.
B) But if your table is, say , of millions of records, and if the physical
location of each record is highly aleatory, the you should use the SQL
statement.Once upon a time I had a 18 million records table, 1.3GB size, so
I know what are you talking about. I think you can do this:
B.1.Create an UniqueId column in the original table, and made an entry in
the CDX with this. This can be very time consuming, but it will promptly
pay off (is it well said???)
B.2. Issue the SQL statement creating a cursor, and make sure you include
the UniqueId column in it.
B.3.Make the cursor writable by issuing
SELECT... INTO CURSOR mycursor... && this is your query
cPhysicalName=DBF() && fetch the physical name of the cursor
USE (cPhysicalName) AGAIN ALIAS mycursor
B.4. Make your changes in the cursor data, using standard browse
techniques.
B.5. When you want to update the data back to the table, you can link the
cursor and the table using the UniqueId column, or use a relationship, or
something like this, and perform the updating process. You can keep the
original table unlocked while you're editing data in the cursor, and lock
it only when the updating process is running. This is called and
"optimistic" editing. If you want more security, you should lock the table
during all the process since the SQL query is made, this is a "pesimistic"
editing.
B.6. You should use the UniqueId column or other combination of
non-editable columns which yield an univocal record id. You cannot use
RECNO() to identify records from the original table in the SQL statement,
the results are always impredictable.
Sorry for the extension, hope this can help.
Greetings from Argentina! (and sorry for my english..missed some lessons
heehee)
Carlos.