Strange problems on decimals - dangerous bug !!

[Marco Turco]

Hi,
there is a really strange problem with decimal using last FWH and XHB versions.
I don't know if it is FW or xHarbour related anyway with my old FWH versions (2012) all runs well.

It's a bit difficult to make a self-contained sample, anyway the problem appear in this case

nDecimals is a numeric value I have read from my database and its value is 3

if I make str(87.877,10,nDecimals) it return 88 instead of 87.877 !!!
if I make str(87.877,10,3) it return 87.877 that is correct

It's a really crazy and Dangerous situation. At the moment I have renstalled the previous FWH/XHB version to go in production.

Any ideas ?

[James Bott]

Hmm, have you checked to make sure that nDecimals is actually 3 and not zero?

MsgInfo( nDecimals == 3 )

[Marco Turco]

Hi James,
I tried and it return .t.

The problem is xHarbour related !!

If I use FWH14.12 with my old xHarbour 1.2.1 rev 9656 all runs fine,
if I I use FWH 14.12 with xHarbour 1.2.3 rev build 20141106 the problem appears.

The xHarbour provided with FWH14.12 is buggy.

[James Bott]

Yes, it would seem that then str() function is the problem. I can't imagine why that needed modification after all these years.

[Marco Turco]

I'm not sure it is str() related, I suppose it is floating point related because it appears just using numbers loaded from a database not with numers manually assigned to a variable.
Antonio, pls. any ideas ?

[James Bott]

I am having a hard time understanding why this is happening if nDecimal == 3.

str() should only be returning an integer if the third value is either zero or not passed. But you checked the value of nDecimal and it is not either zero or nil.

[Antonio Linares]

Marco,

This example is properly working here using both Harbour and xHarbour

Code: Select all | Expand

function Main()

   local nDecimals := 3

   MsgInfo( str(87.877,10,3) )

   MsgInfo( str(87.877,10,nDecimals) )

return nil

I get 87.877 in all cases

[James Bott]

Marco,

It's a bit difficult to make a self-contained sample,

This makes me think that there is something else in your code that is triggering the problem.

Antonio's sample code is only 5 lines of code, so an example is simple. If you are getting it in your code, then it must be something else that is going on.

First, can you run Antonio's example with your suspect xHarbour version and tell us the result (and tell us the version number). Then try compiling your code again with that version and recheck it. If you are still getting the error then there is something else causing the error. It could still be differences in versions of xHarbour, but not in the str() function (as you mentioned).

[Marco Turco]

Hi Antonio,
your sample work well but it is not my case.
In my case the nDecimal value is loaded from a sqlite database. the field is "nDecimal smallint (2)" .
I have also generated the sqlite library using last xharbour version but the problem is always in place.

I will try to make a self contained sample to show you the error.

[Antonio Linares]

Marco,

use nDecimal this way:

Int( nDecimal )

Harbour may be waiting for an integer and you are providing a decimal number

[nageswaragunupudi]

One of the advantages of SqLite is that we can store any datatype in a column of any datatype. This is like storing into and retrieving from an array. This advantage can also be dangerous pitfall at times.

We are not sure at times what we accessed is a string "3" or double 3. or integer 3.
We need to doubly sure of the datatype and if necessary convert into the correct datatype before use.

Please doubly ensure that the value of nDecimal is a Harbour Integer before using it in the function Str(...). Please read the value into a memory variable, check valtype and then use the value.

[James Bott]

Marco,

Gee, you left out a very important bit of information, that you are using SQLite as the database.

Nages,

Is xHarbour capable of dealing with number types other that floating? When nDecimal is loaded from a SQL database with fieldtype "integer" what is valtype() going to return? "Integer?" I would have guessed that all numeric datatypes were converted to floating.

[Marco Turco]

Hi, some more infos:
1. the valtype of the value read from the sqlite db is "N" so numeric that is correct
2. I also make this test: MsgInfo( str(87.877,10,int(nDecimals)) ) and Always return 88 (nDecimal had 3 as value)

This problem didn't exist with xHarbour 1.2.1 rev 9656 but appear with xHarbour 1.2.3 rev build 20141106

I'm working to a self-contained sample...

To Antonio: in the meantime do you think I can use FWH14.12 with xHarbour 1.2.1 rev 9656 ?
The str function runs well in this configuration.

[nageswaragunupudi]

in the meantime do you think I can use FWH14.12 with xHarbour 1.2.1 rev 9656 ?

You can use.

This is the version I am using.
xHarbour 1.2.3 Intl. (SimpLex) (Build 20141106)

Everything is working correctly for me. I tried to simulate the same situation using SqLite3 also.
We await your self contained sample.

[Marco Turco]

Hi Rao,
self contained sample available on http://109.228.12.120/softwaredistribut ... a/test.rar

Test.prg is a very simply self-contained that show the problem reading numeric data from sqlite db.

#include "fivewin.ch"

procedure start()

oSQLite := TSQLiteServer():New( "test.sql" )
If oSQLite:lError
msgStop( "error" )
RETURN
EndIf

cQuery:="SELECT * from t_tables;"
oQry:=oSQLite:Query(cQuery)
nDecimals:=oQry:aData[1,7]
oQry:End()
oSQLite:End()

msginfo(ndecimals) && return 3
msginfo(valtype(ndecimals)) && return N

msginfo(str(88.456,10,3)) && return 88.456
msginfo(str(88.456,10,nDecimals)) && RETURN 88 !!!
return