use again 1

[newtofoxpro]

set exclusive off
use tran.dbf in 0 alias "TranEdit" index tran.cdx order 1
use tran.dbf in 0 alias "TranRead" index tran.cdx again exclusive noupdate order 1

when I have to read data I use "TranRead" and insert/change I use "TranEdit"
anybody finds speed advantage to another user in lan ?

"performance improves because Visual FoxPro does not need to test the status of record or file locks."

Link

Best Regards.

 

[newtofoxpro]

Yes, It does not accelerate read access.

But moving server-dbf to cursor makes select-sql faster.

select * from temp.dbf into cursor tmpRead readwrite
INDEX on line02c TAG one && required time to build

vfp build tmpRead faster on lan. Now the only thing is to sync between tmpRead and tmpEdit. Not tried but I tink datetime() field can help.

product.dbf having 50000 records moved to cursor, lookup/data-picker works fine.

Thanks & Best Regards.

 

[Mike Lewis]

Sorry if you've already answered this, but are you sure you need the index? If you need the index to use SEEK on the cursor, that's fine. But if you only need it in order to display the records in a given order, it might be more efficient to use an ORDER BY clause in the SELECT.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

With select * from temp.dbf into cursor tmpRead readwrite you are really reading all data to a local cursor. And yes, working on that cursor is faster, as you don't work on the server dbf. Syncing back is easier, if you don't query this way, but via view or cursoradapter. These have the needed properties to define what to write back via which keys and more. The READWRITE clause does not allow to write back that easy, it merely allows changing the local cursor.

What you're doing with a readwrite cursor, view or cursoradapter is going in the route of 3 tier development, whereas binding forms/controls to a dbf is 2 tier design.

What's not going well in the long run is selecting all data, the missing part is a where clause limiting your data access. Actually 2 tier data binding to a grid can be faster than querying data, as the grid control itself is very clever in only reading as much, as it displays. So only scrolling makes VFP read more of a DBF. If you query READWRITE, that means all data matching the field list and where clause is read to local memory and/or TEMP dir. If you have a 100MB dbf that strategy is not working well.

And as you discovered already querying does not inherit indexes. That's also true for cursors created by view or cursoradapter. You may not need indexes, if the data loaded into cursors is just a small subset of all data, as is normally the case. In a product database you may want to search in all products, but the result is only what matches your search criteria, just as an example. God indexing of the server side dbfs is essential for fast querying into cursors and from then on you may only use them for sorting without requerying, for relating data in cursors and more. While Mike is right just needing data in one certain order you query with ORDER BY and the query will also make use of a server index, but if you want a grid with header click sorting of each column you also index your cursor data.

Cursors are what equals "the model" in many other development platforms, not only .NET, the model is the loaded data, it might also start empty and load by demand, so called lazy loading, only fetching things first, when really needed. That's an essential thought. If you apply that, it also doesn't matter if the server side has DBF files or a database server.

Bye, Olaf.

 

[newtofoxpro]

Thank you, I am using free tables. How can I call records from tmpEdit not exist in tmpRead. Faster way.

Thank you & Best Regards.

 

[Olaf Doschke]

That's less of a problem using a view, simply Requery. About the same works for Cursoradapter.
But Curors created by a query INTO CURSOR READWRITE have no backreference so you have no means to get new records in any simple way.

You may simply determine maxrecno of your readwrite cursor and append from the dbf for recno()>maxrecno. But you only get new records, not changed records.

In the end a cursor is meant as a snapshot of data as it was when you queried it and only the view or cursoradapter are meant to be used twoways. You can apply views and CA to free tables, too. Views themselves need a database, but you don't need to add the tables to the DBC, you only define the views to free tables in a dbc. And Cursoradapters are classes, they are part of your project sources.

Bye, Olaf.