Thank you !!! Fabio, this is the clearest explanation of what is going on I have seen ( and is regretably missing in the VFP help file )

Thanks to all who have contributed to answering this question. I think I am going to first set my remote view metadata to cast floats as B(16) and see what that gets me. I'll report back.


>>Thanks, I think here at Dow Jones they had that discussion a couple years ago and heartily regret using FP in some cases, but right now any change to the backend schema is not an option, so I have to live with getting fox to float.
>>
>>I think Tamar's mention of variable not having the same range of data types may explain what i'm seeing and I may be able to work around the problem on that basis. It seems properties can still hold float numbers, so if I work with objects a properties I might be able to do this.
>>
>
>VFP compute every numericv operation as float, and every variable is float.
>BUT! every variable or field has a display format.
>When you read MS-SQL data, VFP set the cursor float format to SET("DECIMAL").
>Then you can control it with SET DECIMAL TO or with Cursoradapter.CursorSchema or DB RemoteView metadata.
>
>

>CREATE CURSOR xx (f1 B(0), f15 B(15), f18 B(18))
>APPEND BLANK
>? f1,f15,f18
>REPLACE f1  WITH 1.111111111111111111
>REPLACE f15 WITH f1*2
>REPLACE f18 WITH f1*2
>? f1,f15,f18
>vf1=f1
>? vf1
>? vf1*2
>? vf1*2.000000000000000000000
>vf5=CAST(f1 AS B(5))         && THIS DOESN'T CHANGE THE VALUE!
>? vf5                                     && but change the display value
>? vf5*2.000000000000000000000
>

>
>This visual difference between look value and actual value easily leads to paradoxical situations.
>>
>>>Float type is not precise and better be avoided in SQL Server as well.
>>>
>>>Do you really need very high precision? May be, say, 6 digits after . will be enough? If yes, then define your fields as decimal (20,6) in SQL Server (or take less depending on values you plan to hold).
>>>
>>>Search MSDN T-SQL forum for the associated problems or check Brad Schulz blog
>>>
>>>Quick search brings this thread
>>>http://social.msdn.microsoft.com/Forums/en/transactsql/thread/17c90cbe-018e-4f47-b813-d20d69dcd264
>>>
>>>but I think I read either Brad's or George Mastros blog on this topic also
>>>
>>>http://blogs.lessthandot.com/index.php/DataMgmt/DBProgramming/do-not-use-the-float-data-type
>>>
>>>
>>>>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