anche se non è proprio il forum più indicato... vi è mai capitato un comportamento analogo?
Eseguendo questo esempio, compilato con le versioni aggiornate di xHarbour.com o xHarbour.org, alla seconda iterazione il lock di alcuni record (tipo l'805) non va a buon fine senza una motivazione logica.
L'unica differenza è che la versione compilata con l'xHarbour.org genera il comportamento strano solo se contestualmente crea il dbf, la versione xHarbour.com sempre.
Dopo vari tentativi ho scoperto che ordinando l'array con i record da bloccare pare funzionare, ma non mi sembra molto stabile come soluzione.
- Code: Select all Expand view
- #include "set.ch"
#include "dbinfo.ch"
REQUEST DBFCDX, DBFFPT
FUNC Main()
LOCAL aRek := {797,1197,805,5341,5112,804,9650,3492,3491,807,802,803,1209,9662,5113,808,800,801,806,809,798,811,812,5111,1196,3129,1198,1200,2776,5342,895,2027,1234,5110,5109,799}
LOCAL aStruct := {}
LOCAL n, nRek
rddSetDefault("DBFCDX")
SET DBFLOCKSCHEME TO DB_DBFLOCK_CLIP
IF !os_iswtsclient()
os_netregok(.T.)
ENDIF
set( _SET_MBLOCKSIZE, 64 )
set( _SET_AUTOPEN, 1 )
set( _SET_AUTORDER, 1 )
set( _SET_AUTOSHARE, 1 )
set( _SET_OPTIMIZE, .T.)
disablewaitlocks(.T.)
IF !File("Test.dbf")
aAdd(aStruct, { "ID", "C", 4, 0 } )
dbCreate("Test.dbf",aStruct)
USE ("Test.dbf") NEW
INDEX ON FIELD->ID TAG "I1"
FOR n := 1 TO 9999
Test->(dbAppend())
Test->ID := StrZero(n,4)
NEXT
USE
ENDIF
USE ("Test.dbf") NEW SHARED
FOR n := 1 TO 2
FOR EACH nRek IN aRek
Test->(dbGoTo(nRek))
IF Test->(!dbrLock(RecNo()))
? 'Bad lock', Test->(RecNo())
ENDIF
NEXT
Test->(dbUnlock())
NEXT
? 'End'
RETURN NIL