N is not a good field type here (- .9999999999E+19 to .9999999999E+20)

cast(0 as float) gives N(10,0)
cast(0 as B) gives B(2)
cast(0 as B(16)) gives B(16)

I think B(16) is your best bet

You can change the field type of your remote view - if memory serves

DBSETPROP('Viewname.fieldname, 'field',  'DataType', 'B(16)')

>>Charles,
>>
>>Can you cast as B(16) ?
>
>That seems to get the same result as casting as B
>
>VFP help says float is included for compatibility but is functionally equivalent to numeric. I'm wondering if there is a way to convert these things to very large numerics N(32,10) or something.
>
>(addendum - casting as n(32,10) for the view is not an option)
>
>>
>>>I am hoping some of the serious math wonks will take pity on an old man who still finds long division challenging.
>>>
>>>I have SQL database tables that make heavy use of floating point numbers.
>>>
>>>In my remote view, I am pulling half a dozen of those numbers. The remote view defines them as data type 'B' ( of which I have not previous experience)
>>>
>>>I need to multiply those number together, then put the result in a field I created as part of the remote view ( casting a 0 as float )
>>>
>>>But in the watch window these values all show up as N , even though the values can look like 140333030.002033021000
>>>And when I multiply them the result looks like a float, But when I try to save the value into a view column, I get a numeric data overflow.
>>>
>>>Trying to cast the numbers as B just gets them lopped off after about 4 decimals. ( I think this has something to do with 16bit vs 32 bit math, but since my brain runs on an i386sx chip, it is beyond me )
>>>
>>>I'm sure this problem is nothing new to anyone who has tried it and I found this
>>>
>>>http://fox.wikis.com/wc.dll?Wiki~VFPFloatingPointDataType
>>>
>>>on the wiki.
>>>
>>>But I am trying to wrap my brain around how to employ conversions ( and which of the functions to use ) in pulling, manipulating and hopefully saving the data.
>>>
>>>Really stuck on this one.
>>>
>>>TIA