Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Rushmore, don't get it
Message
De
22/04/2005 03:49:27
 
 
À
22/04/2005 03:42:15
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Versions des environnements
Visual FoxPro:
VFP 6 SP5
OS:
Windows XP SP2
Database:
Visual FoxPro
Divers
Thread ID:
01006860
Message ID:
01007382
Vues:
15
>>>
>>>I'm not sure 100%, but this is correlate with the CHR(0)
>>>( C++ nullString endtag ) and the index string COMPACT routine.
>>>
>>>If you define index with last key char = CHR(0) character, you can to meet this bug
>>
>>hi Fabio,
>>
>>I was thinking the other night there must be something in the key value that makes it fail. Dunno, maybe compact as you say or maybe it uses a bit of the key to indicate whether an index entry is occupied at certain places. I'm just guessing here.
>>But if it does fail for a string( bintoc), then why would it not fail for an integer, which also returns a string ?
>
>Gregory,
>the bug is present on any string key with lenght > 1;
>the COMPACT process is insignificant.
>
>Next is a general repro
>
>clear
>
>	set collate to 'machine'
>
>
>	cPrefix = 'someString' && any string with len>0
>	
>	N = 1  && 1..255
>	
>	create cursor CursorTest ;
>		( 	j_ref		c(LEN(cPrefix)+1) ;
>		)
>	index on j_ref TAG j_ref
>
>	* Start the index with  a fixed sequence
>	FOR k=1 TO 2	&& COMPACT use the recno=1 key
>	  insert into CursorTest values(m.cPrefix+CHR(m.N))  && prefix + not NULL ASCII
>	NEXT
>	* Append a Key with: same prefix, BUT END with NULL CHAR
>	  insert into CursorTest values(m.cPrefix+CHR(0))	
>	? "FOUND",test() AT 20	&& now found it
>	
>	* Append another keys group with the keys equal to that of the start group
>	FOR k=1 TO 10
>	  insert into CursorTest values(m.cPrefix+CHR(m.N))  && prefix + not NULL ASCII
>	  ? "NOT FOUND",test() AT 20
>	NEXT
>	* Append another key with a different key
>	  insert into CursorTest values(m.cPrefix+CHR((m.N+1)%256))
>	
>	? "FOUND",test() AT 20	&& now the gost key it reappears
>
>	
>	PROCEDURE TEST
>	  REINDEX
>	  RETURN KEYMATCH(m.cPrefix+CHR(0))
>
>
>For integers index VFP uses a different C++ routine,
>and the bug is not present
>
>clear
>
>	set collate to 'machine'
>
>	cPrefix = '340133' && any string
>	
>	N = 1  && 1..255
>	
>	create cursor CursorTest ;
>		( 	j_ref		I ;
>		)
>	index on j_ref TAG j_ref
>
>	insert into CursorTest values(0x01&cPrefix)  && prefix + not NULL ASCII
>	
>	* Append a Key with: same prefix, BUT END with NULL CHAR
>	insert into CursorTest values(0x00&cPrefix)	
>	? "FOUND",test() AT 20	&& now found it
>	
>	* Append another keys group with the keys equal to that of the start group
>	FOR k=1 TO 10
>	insert into CursorTest values(0x01&cPrefix)  && prefix + not NULL ASCII
>	? "NOT FOUND",test() AT 20
>	NEXT
>	* Append another key with a different key
>	insert into CursorTest values(0x00&cPrefix)
>	
>	? "FOUND",test() AT 20	&& now the gost key it reappears
>	
>	PROCEDURE TEST
>	REINDEX
>	RETURN KEYMATCH(0x00&cPrefix)
>
>
>The presence of the bug until version 8,
>depends on the fact that is rare to have strings that they finish with CHR_0,
>and nearly nobody uses BINTOC.
>In VFP9, BINTOC has been upgraded
>(still lacks the LOGICAL, the DATES and the DATETIME support),
>and therefore the bug would have appeared a lot soon;
> however now is resolved.
>
>Still the master rule:
>
>the bugs exists, also when they are not looked at
>

>
>Fabio

Fabio,
thanks, I will look into this later. Cannot now, I have an interrupt on an interrupt from a customer
Gregory
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform