Problem with ADT integer on xharbour december build

[Gianni]

This little example create a simple ADT table with some integer fields.
It works with xharbour november build and show right values:

10000000
10000
100

with xharbour december build (and last CVS too!!!) don't works and show this:

****
****
**

Any suggestion?
Regards

Code: Select all  Expand view  RUN

#INCLUDE "ADS.CH"
#include "FiveWin.ch"

function Main()

   rddRegister( "ADS", 1 )
   rddsetdefault( "ADS" )
   SET SERVER LOCAL
   SET FILETYPE TO ADT

   DbCreate( "testadt.adt", { { "field1", "N", 8, 0 },;
                              { "field2", "N", 5, 0 },;
                              { "field3", "N", 3, 0 } } )

   USE testadt

   testadt->(dbappend())
   testadt->field1 := 10000000
   testadt->field2 := 10000
   testadt->field3 := 100
   testadt->(dbcommit())

   testadt->(dbgotop())
   testadt->(msginfo(str(field1) + CRLF + str(field2) + CRLF + str(field3)))

   USE

return nil



[fgondi]

Gianni,

This looks Post:
http://fivetechsoft.com/forums/viewtopic.php?t=9079&highlight=

The problem is the function str()
Used str( field1, 11) instead of str( field1 )

[Gianni]

Thank for answer
I don't think is a "str()" problem because
padl(field1,8,"0") returns "0000****"
and
padr(field1,8,"0") returns "****0000"
and this happen with xharbour december build and ONLY with ADT tables

[fgondi]

Gianni,

Correct.
It is not the function str(). These are all functions of converting numbers to characters from xharbour december build

[Gianni]

Any news about this problem?
It's still in last xharbour (02/2008).

Regards

[Antonio Linares]

Gianni,

Have you reported this bug to the xHarbour newsgroup ?

If not, we kindly request you to do it. Thanks,

[toninhofwi]

This "problem" is in both Harbour/XHarbour. Please, see my next posts that are adressed to harbour developer list:

---cut---
Hi ppl,

With ADS, if the double field have large values like 1234567890123,
harbour displays ******** instead a value.

If I use str(field,20) the value is displayed correct.

A sample is in: http://www.fwi.com.br/toninho/adsdouble.zip

Thanks and best regards,

Toninho.
---cut---


---cut---
Przemek says:

Not only double. In ADS* RDDs non of numeric binary field sizes is
translated to valid size for decimal representation, f.e. the same
is for short ("I"/"short",2,0) and integer ("I"/"integer",4,0) when
the decimal representation will be bigger then 2 or 4 digits.
In each numeric item we keep default size for str() formating and
ADS RDDs sets this size to binary field size instead of maximum size
for binary representation. AFAIR this problems exists from the beginning.
It's ***only formatting*** problem when you do not explicitly set the size
but if you want to fix it then you should set valid size in adsGetValue()
function. It will be few lines only. You can take maximum sizes for all
types from dbf1.c or other RDDs I was working on (f.e. s_uiNumLength
translation table in delim1.c can be used for all integer sizes in
range 1,8)

Best regards,
Przemek
---cut---