>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 )
you are welcome.
>
>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))
>>? vf5
>>? 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
