Am Dienstag, den 30.04.2013, 21:10 -0700 schrieb Paul McNett:

> On 4/30/13 12:22 PM, Ed Leafe wrote:

> > On Apr 30, 2013, at 1:50 PM, Max Voß <max.voss@optik-stahr.de> wrote:

> >

> >> That is strange, it is in fact a problem with the conversion of my

> >> float-fields when I change the db-fields from float to decimal-type,

> >> what is the better choice anyway, everything works like a charm. But I

> >> probably should open a ticket for that behaviour, since that isn't what

> >> it is supposed to do with float-fields, right?

> >

> > There is a setting: convertFloatToDecimal. This defaults to True, so yes, it is expected behavior.

> >

> > Paul wrote much of that code and probably has more experience with the float-to-decimal conversion, so I'm hoping he might chime in here.

>

> I will try to find time to look into this tomorrow (Wed.). I've been planning on

> releasing 0.9.10 but I also have a list a mile high for clients. We'll see...

>

> Paul

Hi Paul,

I think I can provide you some additional information for this problem:

The float to decimal conversion is not a problem per se, but seems to

become one in the newer dabo-versions in combination with mysql. Since

mysql stores float-values following the standards without any

specification of the precission. (read here:

http://dev.mysql.com/doc/refman/5.0/en/floating-point-types.html )

When I change my problematic "preis"-field from float without precission

specification to a float(7,2) for example, dabo has no problem at all

with the conversion.

So my guess is that dabo has no, or a wrong default-value for the

precission of float-values. But that is just a guess.

After I looked into the code I am more confused then ever. I added in

the dabo/db/dCursorMixin.py some debug output:

272 print "field_val: %s" %(_field_val)

273 print len(_field_val.split(".")[1])

274 if scale is None:

275 try:

276 scale = len(_field_val.split(".")[1])

277 except (IndexError, AttributeError):

278 scale = 2

279 print "_field_val: %s scale: %s" % (_field_val, sca le, )

and that is what I get before the error occurs:

field_val: 135.0

1

_field_val: 135.0 scale: 31

scale: 31 dec: 135.0

Where the heck does the 31 come from? Why does

len(_field_val.split(".")[1]) returns 1 before the try-catch but 31 if

it is called in the try-catch-block.

I am definitly missing something here, but perhaps you can enlighten me.

Max

_______________________________________________

Post Messages to: Dabo-users@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/dabo-users

Searchable Archives: http://leafe.com/archives/search/dabo-users

This message: http://leafe.com/archives/byMID/1367571721.3654.94.camel@t60