On Tue, 29 Dec 2009, Mindaugas Kavaliauskas wrote:
Hi,
> I have a question/discussion about DBSEEK(). I've started from the
> different ADSCDX and DBFCDX behavior and later included Clipper
> tests.
> #ifdef __HARBOUR__
> REQUEST ADSCDX
> #endif
> REQUEST DBFCDX
> FIELD F
> FUNC main(cADS)
> IF EMPTY(cADS)
> RDDSETDEFAULT("DBFCDX")
> ELSE
> RDDSETDEFAULT("ADSCDX")
> ENDIF
> ? VERSION(), RDDSETDEFAULT()
> DBCREATE("test187", {{"F", "N", 5, 0}},, .T.)
> OrdCreate("test187", "f", "F")
> DBAPPEND(); F := 1
> DBSEEK(10, .T., .F.)
> ? RECNO()
> DBSEEK(10, .T., .T.)
> ? RECNO()
> DBCLOSEALL()
> RETURN 0
> The code above prints:
> C:\cawi32\sample\test>test187.exe
> Harbour 2.0.0 (Rev. 13372) DBFCDX
> 2
> 1
> C:\cawi32\sample\test>test187.exe xxx
>
> Harbour 2.0.0 (Rev. 13372) ADSCDX
> 2
> 2
> C:\cawi32\sample\test>test187.exe
> Clipper (R) 5.2e Intl. (x216) (1995.02.07) DBFCDX
> 2
> 2
Clipper 5.2 does not support 3-rd parameter <lLast> in dbSeek()
function. This is only CL5.3 DBFCDX feature.
> So, I looks like Harbour's DBFCDX is wrong and ADSCDX is OK, but my
> co-worker said, that Clipper has bugs in softseek. I've tried
Harbour results are correct and are the same as in CL53/COMIX CDX
implementation. Seek last with softseek on should fully revert the
positioning order and when exact key cannot be found should stop
at 1-st smaller value (1 in 1-st record in your example) or at EOF
if smaller value does not exists (try: DBSEEK(0, .T., .T.))
I have no idea if seek last in ADS works correctly or not.
> another test:
> REQUEST DBFCDX
> #ifdef __HARBOUR__
> REQUEST ADSCDX
> #endif
> FIELD F
> PROC main(cADS)
> IF EMPTY(cADS)
> RDDSETDEFAULT("DBFCDX")
> ELSE
> RDDSETDEFAULT("ADSCDX")
> ENDIF
> ? VERSION(), RDDSETDEFAULT()
> DBCREATE("test188", {{"F", "N", 5, 0}},, .T.)
> OrdCreate("test188", "f", "F")
> DBAPPEND(); F := 1
> DBAPPEND(); F := 1
> DBAPPEND(); F := 3
> DBAPPEND(); F := 3
> DBSEEK(2, .T., .F.)
> ? RECNO()
> DBSEEK(2, .T., .T.)
> ? RECNO()
> DBCLOSEALL()
> RETURN
> It prints:
> C:\cawi32\sample\test>test188.exe
> Harbour 2.0.0 (Rev. 13372) DBFCDX
> 3
> 2
So Harbour DBFCDX results are correct.
> C:\cawi32\sample\test>test188.exe xxx
> Harbour 2.0.0 (Rev. 13372) ADSCDX
> 2
> 2
Interesting, looks like both forward and backward seek gives wrong
results in ADS.
> C:\cawi32\sample\test>test188.exe
> Clipper (R) 5.2e Intl. (x216) (1995.02.07) DBFCDX
> 5
> 5
Passing 3 parameters to dbSeek() in CL5.2 breaks the second one.
If you remove the 3-rd parameter then you will have:
3
3
and these are expected Harbour native RDDs compatible results for
forward seek.
> So, we have a different behavior for all of RDD's, and I seems
> Clipper ignores softseek at all.
No. CL5.2 does not support 3-rd parameter in DBSEEK() and using it breaks
the second one. If you fix your test code to be CL5.2 compatible then
it gives the same results as Harbour.
Only ADS seems to be broken. I still cannot find 64 bit ADS local
server client for Linux so I cannot test it and confirm your results
so I cannot tell you if it's Harbour ADSRDD or ADS/ACE problem which
should be reported to Extended System.
> From a printed (CL53) reference guide vol.1 page 2-315 I can read:
> "<lLast> is specified as true (.T.) to seek the last occurence of
> the specified key value." , but it is not clear how it works if
> specified key does not exists. I can also read on the same page:
> "... for a soft seek, the work area is positioned to the first
> record whose key value is greater than the specified key value. If
> no such record exists, the work area is positioned to LASTREC() + 1
> and EOF() returns true (.T.)".
It's defined indirectly by dynamic descend flag which causes
that seek last should work like in Harbour native RDDs and
CL53/COMIX. In such implementation seek last is fully revertible
by switching to descending order ( ordDescend(,,!ordDescend()) )
and forward seek. Otherwise we will have some anomalies.
> So, in the latter sample (test188) I would expect:
> 3
> 4
No. 3 and 2.
> but not any of the above results from various tests.
> *** So, how soft seek and last seek should work? ***
Just like in Harbour native RDDs.
> The question becomes even more complicated if think about DESCENT index.
No, in clear implementation there is no problem at all (see above)
and in Harbour all native RDDs fully respects seek last in ascending
and descending orders also with dynamic descond flag.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
