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 && this is the line I need
	do case
	case !m.Success
		exit

	case !seek(m.SeekKey, 'TaxDriverOutput', 'Id')
		assert FALSE
		Success = FALSE

	case TaxDriverOutput.td_code <> m.SeekKey && this one fails without the GO TOP
		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