>>>A long time ago I got into the habit of never assuming whether a dropdown combobox would return vartype C or N when I was expecting N.
>>>
>>>So, when retrieving what I want to be a numeric value I do:
>>>
>>>lnValue=val(transform(thisform.cbo.value))
>>>
>>>doing it this way, I don't have to test for vartype
>>>
>>>I came across a quirk yesterday.
>>>
>>>I have a combobox on a form that has a rowsourcetype as 3 - SQL Statement
>>>
>>>the SQL statement does select somecharfield,someintfield from sometable into cursor somecursor
>>>
>>>BoundTo=.T.
>>>BoundColumn=2
>>>ControlSource=thisform.nValue
>>>
>>>When someintfield = 1234567
>>>then
>>>val(transform(thisform.cbo.value))=1234567
>>>val(transform(thisform.nvalue))=1234567
>>>
>>>However:
>>>When someintfield=12345678
>>>then
>>>val(transform(thisform.cbo.value))=0
>>>but,
>>>val(transform(thisform.nValue))=12345678
>>>
>>>checking into this further
>>>thisform.cbo.value=12345678.0
>>>thisform.nValue=12345678.00
>>>
>>>and
>>>
>>>transform(thisform.cbo.value)="*******.**"
>>>transform(thisform.nValue)="12345678"
>>>
>>>but if I
>>>transform(12345678.0)="12345678"
>>>
>>>
>>>What. The. Hell.?
>>
>>Is there a ControlSource for the combo? Might the longer value have overflowed the ControlSource?
>>
>>Tamar
>
>
>ControlSource=thisform.nValue
>
>and
>
>transform(thisform.cbo.value)="*******.**"
>but
>transform(thisform.nValue)="12345678"

Ah, you did say that before. Sorry. I'm still wondering about some kind of numeric overflow, but I can't see how it would happen if there's no field in sight.

Tamar