>>>? ">" + transform( my_variable ) + "<" >
>>
>>Recently I had a nasty surprise with this. I had a loop to name the variables to use in a macro (because I had to loop through field1, field2, field3, ..., field45), and I used
>>

cFieldName="field"+tran(i)

>>where i was the loop counter. To my surprise, when it ran it banged on
>>

cValue=eval(cFieldName)

>>because the value in cFieldName was Field1.000000000 - probably the loop counter got created with some accidental (?) decimals. Luckily, I knew that the structure of the table will not change and that field1 is the 10th field, so I used
>>

cValue=eval(fields(i+9))

>>instead. Still, this accident got me thinking... will tran(integer) always yield a string representation of a number without a decimal point, or is it something to watch out for and code around.
>
>Dragan,
>
>It's a known fact, that transform has a bug. See this KB artcile for details

Seems to be the slight differences in the value of i tend to be displayed to the maximal precision in transform() without the second parameter - they actually are there, but usually not visible and not displayed. Here's the routine from the article, slightly modified:

CLEAR
cCompatible = SET("COMPATIBLE")
SET COMPATIBLE OFF
? "Precision automatically jumps to 15 decimal places "
? "with overflows displayed at 1.6"

FOR i = 1 TO 3 STEP .1
	? i, i-round(i,15), TRANSFORM(i)
ENDFOR
SET COMPATIBLE &cCompatible 

Putting any other value for the number of decimals in round(), I had a perfect column of zeros, only for 15 it's a -1e-15 there, for values of 1.5 and 2.5. Still the error I had didn't come from any accumulation of 0.1's - it kicked in with the initial value. If Transform() only respected the Set Decimals, it'd be allright.