GNOME Bugzilla – Bug 499459
Error with calculation fields in an Spanish Desktop
Last modified: 2007-11-28 10:03:08 UTC
Please describe the problem: I have created a number filed (named number). Then I have created a second field: This is a calculation field that do: return record["number"] * 100 When I write one number (1) in the field number and then I press Return, I get the error in a box: ERROR: error de sintaxis en o cerca de «000000» LINE 1: UPDATE "contacts" SET "calculado" = 1,000000 WHERE "contact_... and in the command line: ERROR: error de sintaxis en o cerca de «000000» en carácter 39 SENTENCIA: UPDATE "contacts" SET "calculado" = 1,000000 WHERE "contact_id" = 4 Internal Error (Base_DB::handle_error()): exception type=N5Gnome3Gda15ConnectionErrorE, ex.what()=ERROR: error de sintaxis en o cerca de «000000» LINE 1: UPDATE "contacts" SET "calculado" = 1,000000 WHERE "contact_... I think my system is using the spanish decimal separator (,) and postgre is using the dot (.). In number fields all works fine but in calculated fields doesn't work. IMO the problem is you are controlling the decimal separator when you update a simple field but not when is a calculated field. Regards and thanks for Glom!!!! Steps to reproduce: Actual results: Expected results: Does this happen every time? yes Other information:
I am trying with a lot of options (changing use 2 decimals, miles separator etc. )but nothing ...
I'm using postgre 8.2 in Ubuntu 7.10 with ubuntu glom package
> In number fields all works fine but in calculated fields doesn't work. IMO the > problem is you are controlling the decimal separator when you update a simple > field but not when is a calculated field. I guess that's possible, though I don't know yet where the problem would be. It could be in our use of Python, I suppose.
The problem is in Conversions::get_text_for_gda_value Line: 274 return value.to_string(); before do to_string, gda_value have the correct value (4000) and executing .to_string() we get 4000,000000. I think the error is: 1.- Creation of the Gda::Value, that not is a GDA_TYPE_NUMERIC or 2.- Handling gda types is not correct. I need that you check this because i cannot change the Gda::Value creation or the gda types handling. You know better the source and you should decide what we must to touch. If you want I can try to change it but I need study this a bit.
Yeah, .to_string() should probably be avoided because I guess it uses the current locale (But SQL expects a canonical representation), and it's generally only meant for debug output. I'll take a look. Thanks.
I believe that this change has fixed it. Please test: 2007-11-27 Murray Cumming <murrayc@murrayc.com> * glom/libglom/data_structure/glomconversions.cc: convert_value(): Deal with gint values specially, because we usually really do want to convert gints to GdaNumerics, though we do use gints for some serial keys. (I think, but maybe not anymore.) * glom/python_embed/glom_python.cc: glom_evaluate_python_function_implementation(): Make sure that the we return an appropriate value type, by calling convert_value(), because pygda_value_from_pyobject() would not necessarily return exactly what we want. This seems to fix bug #499459 (Perriman) so that numeric calculations do not cause SQL errors in non-English locales.
Perfect!! Calculation now works fine in a Spanish environment! Thanks a lot, Murray!!