Gregory
>
>Last week I came across a situation where I HAD to put a go top
>Without the GO TOP, the seek() returns TRUE, but the record pointer is not on the record >> last ASSERT
>I couldn't think of any reason
Disturbing, to say the least!
for i = 1 to m.nToDo
SeekKey = eval(ToDo[m.i])
if( empty(m.SeekKey) )
loop
endif
IsOutputLine = TRUE
go top in TaxDriverOutput
do case
case !m.Success
exit
case !seek(m.SeekKey, 'TaxDriverOutput', 'Id')
assert FALSE
Success = FALSE
case TaxDriverOutput.td_code <> m.SeekKey
assert FALSE
Success = FALSE
As long as TaxDriverOutput.td_code is the index expression of "ID" and you have not switched set exact, m.SeekKey or the record pointer interrupt-like between the two cases it seems seek() is not to be trusted always in vfp9. The other possibilities (compound index ID for instance) I can momentarily think of you would surely have checked yourself, spelling inconsistencies like
td_code shouldn't be "healed" by a go top. [sigh]
Did you report this back to MS ?
Do you have a sample of the 'TaxDriverOutput' table and the Todo-Array for me to play around with ? Perhaps the error crops up only when using the seek() with 3 parameters or a special combination of currently set index. But working off wrong records might kill some of my projects/contracts ABRUPTLY, so I'ld like to find out more about the scope of this bug. I was quite rigorous in eliminating "go top" as it can incur quite a penalty if used on tables with filters or indices set, wheras an empty locate is often faster there - but this might also be bitten, if it is something index-related.
regards
thomas