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ß <[email protected]> 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: [email protected] 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
