Antonio Linares wrote:I would like to ask you for your experiences regarding slow performance RDDs:
1. What RDD were you using ?
Antonio Linares wrote:2. An upgrade of Harbour (or xHarbour) solved it ?
Antonio Linares wrote:3. Was it related to a certain Windows version ?
Antonio Linares wrote:4 Was it related to the network ?
Antonio Linares wrote:5. How did you fixed it ?
* Windows Server 2003 with an app that opens a DBF with its CDX.
* Windows 7 from the client side, using the same DBF opened in the server. The problem could be related to the index as on each dbskeep/dbseek it has to consult the server).
* On this scenario just moving up and down a browse, the app slows down visibly.
* It seems that it is related to DbSkip and DbSeek
4 Was it related to the network ?
90% true ,much issues like disables smb2, review the hardware, etc
SET TURBOREAD:
Syntax:
SET TURBOREAD [ON | OFF]
This command allows you to turn-off the automatic locking of index
files during certain read-only processes, ie: SEEK, GO TOP, SKIP, FIND,
etc. This powerful feature has one serious side-effect: IT ALLOWS
OTHERS TO UPDATE YOUR INDEX WHILE YOU ARE SEARCHING IT! Basically,
this means that even though your SEEK may return a FOUND() = .T.
status, if the index was changed during the SEEK process, it would not
necessarily be accurate. That's why we call it a "dirty" read. <g>
To offer some type of solution to this integrity problem, semaphore
management functions (Sx_MakeSem(), Sx_KillSem(), etc) have been included
so that you may have a mechanism through which you can inform other network
users that you are in the SEEK process. With this, they can be forced to
wait until your process is complete before performing the index file
update.
NOTE: Using this function, while somewhat risky, will improve your
network performance by up to 100%, so weigh the options carefully.
NOTE: This command is NOT supported under SIXNTX.
Example:
/*
This program demonstrates the speed difference dirty read makes when
skipping though a shared database.
*/
#include "SIXNSX.CH"
LOCAL nStart, nEnd
SET EXCLUSIVE OFF // Make SHARED the default
USE TEST VIA "SIXNSX" // Open up the TEST database
INDEX ON last TO last // Build an index; Since it's exclusive after
CLOSE DATA // just creating it, close the database and
USE TEST VIA "SIXNSX" // reopen it
SET INDEX TO LAST // Then set our index active again
? "Skip test - shared"
?
nStart := Seconds() // Save starting time
FOR nCnt := 1 TO 240 // Cruise through the database for a bit
?? "." // Print a dot
DO WHILE !eof() // Skip to the end of the file
SKIP
ENDDO
DO WHILE !bof() // Skip back to the beginning of the file
SKIP -1
ENDDO
NEXT
nEnd := Seconds() // Save ending time
? "Elapsed time:", nEnd - nStart, "seconds"
?
// Now turn dirty read on
SET TURBOREAD ON
? "Skip test - shared with dirty read on"
?
nStart := Seconds() // Save starting time
FOR nCnt := 1 TO 240 // Cruise through the database for a bit
?? "!" // Print an exclamation point
DO WHILE !eof() // Skip to the end of the file
SKIP
ENDDO
DO WHILE !bof() // Skip back to the beginning of the file
SKIP -1
ENDDO
NEXT
nEnd := Seconds() // Save ending time
? "Elapsed time:", nEnd - nStart, "seconds"
Antonio Linares wrote:I would like to ask you for your experiences regarding slow performance RDDs:
1. What RDD were you using ?
2. An upgrade of Harbour (or xHarbour) solved it ?
3. Was it related to a certain Windows version ?
4 Was it related to the network ?
5. How did you fixed it ?
I think this information will be useable by some Harbour and FWH users, especially for those that don't use the most recent versions. Thanks
The slow performance are due to deleted records but we can't use the INDEX ... FOR !Deleted()
Code: Select all | Expand
function TurnShared( lOnOff )
return dbInfo( DBI_SHARED, lOnOff )