FPw2.6 Browse again 
Author Message
 FPw2.6 Browse again

I posted a message earlier and got several answers about a quick way to
bring up a group of records in a browse without using set filter to.

The problem with using rushmore: it is important to set order to 0 ,
therefore this huge browse is not in any particular order.  This
solution was fast too!

Browse Key acted really weird in this huge database, it came up with the
browse fast, but paused FOREVER everytime you wanted to move down
through the data.

Any other solutions?

SQL is fast, but I need to update a field in this database.



Sun, 27 Aug 2000 03:00:00 GMT  
 FPw2.6 Browse again

Hi Lisa:

    Send use the entire BROWSE command line that you are using, and a list
of all the index tags that are associated with the table.  Lets see if we
can identify any problems.

--Paul

Quote:

>I posted a message earlier and got several answers about a quick way to
>bring up a group of records in a browse without using set filter to.

>The problem with using rushmore: it is important to set order to 0 ,
>therefore this huge browse is not in any particular order.  This
>solution was fast too!

>Browse Key acted really weird in this huge database, it came up with the
>browse fast, but paused FOREVER everytime you wanted to move down
>through the data.

>Any other solutions?

>SQL is fast, but I need to update a field in this database.



Sun, 27 Aug 2000 03:00:00 GMT  
 FPw2.6 Browse again

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.



Tue, 29 Aug 2000 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Slooooow BROWSE - here I go again....

2. USE AGAIN is at it again

3. Not a table: Once and again (and again)

4. browse, browse, browse

5. FPW2.6 Browse order switching

6. Help. FPW2.6 Changing browse field without moving

7. FPW2.6 Browse will not display under VFP5 ???

8. FPW2.6a Browse Problem

9. Edit regions and Browses in FPW2.6

10. FPW2.6 General Browse Questions

11. FPW2.6 Editing field within browse

12. FPW2.6 Using Browse

 

 
Powered by phpBB® Forum Software