Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Invalid Seek Offset - reproducible
Message
From
23/07/2006 08:42:06
 
 
To
23/07/2006 06:49:57
Thomas Ganss (Online)
Main Trend
Frankfurt, Germany
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Environment versions
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01137918
Message ID:
01138904
Views:
11
>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

Thomas,

I cannot reproduce it with a couple of small cursors

But if I repeat the seek if necessary, I can get rid of the GO TOP

There are two cases as far as I can see
(1) the seek returns TRUE and the record pointer did not move. A second seek resolves it

(2) the seek returns FALSE, a second seek the returns TRUE


All this works on cursors and in vfp6
case !seek(m.SeekKey, 'TaxDriverOutput', 'Id') and !seek(m.SeekKey, 'TaxDriverOutput', 'Id') && case (2)
	assert FALSE
	Success = FALSE
			
case (TaxDriverOutput.td_code <> m.SeekKey) and !seek(m.SeekKey, 'TaxDriverOutput', 'Id') && case (1)
	assert FALSE
	Success = FALSE

case (TaxDriverOutput.td_code <> m.SeekKey)
	assert FALSE
	Success = FALSE
Gregory
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform