The prove of VFP caching data
VFP caches data whenever it can to have light of speed performance is not something new to VFP developer.
That day when I was doing maintenance on my client database, I used my *KISS* table recovery steps to repair tables.
SELECT * ;One of the table contains 500,000 records with size ~100MB.
FROM myTable ;
WHERE .T. ;
INTO CURSOR myCursor NOFILTER
SELECT myTable
ZAP
APPEND FROM DBF("myCursor")
Everything worked fine beside of I got to wait for about a minute in order to close the table. I saw WinXP networking monitor was showing something is acrossing the network. I think VFP is *flushing* data back to server.
The VFP caching is good in general, however it causes delay update. Which means you may not see changes made by another user or application immediately. This limitation actually causes my custom Data Replication program fails to get the latest data sometime. Turning Write Cache off, FLOCK() and issue FLUSH after TABLEUPDATE() are not alway help in my experience. My current workaround is asking my clients to run Data Replication when their shop open every day before any sales.
Thank you FoxTeam to enhance FLUSH command and SET REFRESH option in VFP9. According to documentation, these two enhancements should solve my problems above. However, I dare to test it in my client machine. (It never happen in my office's machines)
0 Comments:
Post a Comment
<< Home