Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Invalid Seek Offset - reproducible
Message
De
23/07/2006 08:42:06
 
 
À
23/07/2006 06:49:57
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP
Database:
Visual FoxPro
Divers
Thread ID:
01137918
Message ID:
01138904
Vues:
12
>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
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform