Hello, In the list of data types, when we want to create a field in a table with the table editor, there is not DECIMAL or NUMERIC (data types that exist in Firebird SQL Server 2.5). Is this an omission or is this intentional? Regards, Bernard Ribot
Can confirm this for OpenSUSE 12.3 64bit and L= 4.2.0.4. No possibility to save a Decimal value.
Adding as blocker for making Firebird the default
On pc Debian x86-64 with master sources updated yesterday or 4.2 sources updated some days ago, I don't reproduce this (or perhaps missed the point). For the test, could you give a try to 4.2 daily build (see http://dev-builds.libreoffice.org/daily/libreoffice-4-2/) or master sources (future 4.3.0) daily build (see http://dev-builds.libreoffice.org/daily/master/)
Forget my last comment.
Hi, I forgot ;-)) I verified with version 4.3.0.0.alpha1+ Build ID: 20778b037c688759a4dc46acb8aeb66c9d1290cc TinderBox: Win-x86@39, Branch:master, Time: 2014-05-03_23:16:12 Data type DECIMAL/NUMERIC is not present. Regards, Bernard
Code pointer: http://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/firebird/DatabaseMetaData.cxx#947 Other I suppose Doc pointers: 1) http://www.firebirdfaq.org/faq340/ " In SQL Standard, NUMERIC is a more strict datatype which should enforce the declared precision, while DECIMAL can accept more numbers than declared. However, in Firebird, both types accept more numbers (i.e. they behave like DECIMAL). " 2) http://www.firebirdsql.org/en/sql-conformance/ " NUMERIC is not compliant and represents almost the same semantics as DECIMAL " 3) http://www.firebirdsql.org/en/firebird-technical-specifications/ " Name: Numeric (precision, scale) Size: Variable (16, 32, or 64 bits) Range/Precision: specifies exactly precision digits of precision Description: Example: Numeric(10,3) holds numbers accurately in the following format: ppppppp.sss Name: Decimal (precision, scale) Size: Variable (16, 32, or 64 bits) Range/Precision: specifies at least precision digits of precision Description: Example: Numeric(10,3) holds numbers accurately in the following format: ppppppp.sss "
Ref for data type: offapi/com/sun/star/sdbc/DataType.idl
I tried to begin to add NUMERIC and DECIMAL but I got this: diff --git a/connectivity/source/drivers/firebird/DatabaseMetaData.cxx b/connectivity/source/drivers/firebird/DatabaseMetaData.cxx index bff558c..6850863 100644 --- a/connectivity/source/drivers/firebird/DatabaseMetaData.cxx +++ b/connectivity/source/drivers/firebird/DatabaseMetaData.cxx @@ -936,6 +936,20 @@ uno::Reference< XResultSet > SAL_CALL ODatabaseMetaData::getTypeInfo() sal_Int16(ColumnSearch::FULL)); // Searchable aRow[12] = new ORowSetValueDecorator(sal_True); // Autoincrement } + // SQL_NUMERIC + aRow[1] = new ORowSetValueDecorator(OUString("NUMERIC")); + aRow[2] = new ORowSetValueDecorator(getColumnTypeFromFBType(SQL_NUMERIC)); + aRow[3] = new ORowSetValueDecorator(sal_Int16(15)); // Precision + aRow[14] = new ORowSetValueDecorator(sal_Int16(1)); // Minimum scale + aRow[15] = new ORowSetValueDecorator(sal_Int16(15)); // Max scale + aResults.push_back(aRow); + // SQL_DECIMAL + aRow[1] = new ORowSetValueDecorator(OUString("DECIMAL")); + aRow[2] = new ORowSetValueDecorator(getColumnTypeFromFBType(SQL_DECIMAL)); + aRow[3] = new ORowSetValueDecorator(sal_Int16(15)); // Precision + aRow[14] = new ORowSetValueDecorator(sal_Int16(1)); // Minimum scale + aRow[15] = new ORowSetValueDecorator(sal_Int16(15)); // Max scale + aResults.push_back(aRow); But I got this: /home/julien/compile-libreoffice/libreoffice/connectivity/source/drivers/firebird/DatabaseMetaData.cxx: In member function ‘virtual com::sun::star::uno::Reference<com::sun::star::sdbc::XResultSet> connectivity::firebird::ODatabaseMetaData::getTypeInfo()’: /home/julien/compile-libreoffice/libreoffice/connectivity/source/drivers/firebird/DatabaseMetaData.cxx:941:69: error: ‘SQL_NUMERIC’ was not declared in this scope aRow[2] = new ORowSetValueDecorator(getColumnTypeFromFBType(SQL_NUMERIC)); ^ /home/julien/compile-libreoffice/libreoffice/connectivity/source/drivers/firebird/DatabaseMetaData.cxx:948:69: error: ‘SQL_DECIMAL’ was not declared in this scope aRow[2] = new ORowSetValueDecorator(getColumnTypeFromFBType(SQL_DECIMAL)); ^ I've got no idea where these must be declared, any idea?
Adding self to CC if not already on
I noticed that DECIMAL and NUMERIC were in fact subtypes. Here's part of code from firebird (isql/isql.h= // Integral subtypes const int MAX_INTSUBTYPES = 2; static const SCHAR* Integral_subtypes[] = { "UNKNOWN", // Defined type, NTX: keyword "NUMERIC", // NUMERIC, NTX: keyword "DECIMAL" // DECIMAL, NTX: keyword }; isql/extract.epp and isql/show.epp show that they're subtypes of SMALLINT, INTEGER and BIGINT, example from first file : 438 if (isqlGlob.major_ods >= ODS_VERSION10) 439 { 440 // Handle Integral subtypes NUMERIC and DECIMAL 441 if ((FLD.RDB$FIELD_TYPE == SMALLINT) || 442 (FLD.RDB$FIELD_TYPE == INTEGER) || 443 (FLD.RDB$FIELD_TYPE == BIGINT)) 444 { 445 FOR FLD1 IN RDB$FIELDS WITH 446 FLD1.RDB$FIELD_NAME EQ FLD.RDB$FIELD_NAME 447 /* We are ODS >= 10 and could be any Dialect */ 448 if (!FLD1.RDB$FIELD_PRECISION.NULL) 449 { 450 /* We are Dialect >=3 since FIELD_PRECISION is non-NULL */ 451 if (FLD1.RDB$FIELD_SUB_TYPE > 0 && 452 FLD1.RDB$FIELD_SUB_TYPE <= MAX_INTSUBTYPES) 453 { 454 sprintf (Print_buffer, "%s(%d, %d)", 455 Integral_subtypes[FLD1.RDB$FIELD_SUB_TYPE], 456 FLD1.RDB$FIELD_PRECISION, 457 -FLD1.RDB$FIELD_SCALE); 458 precision_known = true; 459 } 460 } 461 END_FOR 462 ON_ERROR 463 ISQL_errmsg (isc_status); 464 return ps_ERR; 465 END_ERROR; 466 } 467 }
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT: - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-01-17
Bug still exists unde LO 5.1.0.2, OpenSUSE Leap 42.1, 64bit rpm Linux.
Hi, Bug always present with : Version: 5.1.0.2 Build ID: ecd3574d51754b043f865cf5bafee286d24db7cc CPU Threads: 2; OS Version: Windows 6.1; UI Render: default; Locale : fr-FR (fr_FR) on Win7/x86 Data typrs present in Base : Biglnt [ BIGINT ] Texte (fixe) [CHAR] Integer [ INTEGER ] Small Integer [ SMALLIrJT ] Float[FLOAT] Double [ DOUBLE PRECISION ] Texte [ VARCHAR ] Date [DATE] Heure [TIME] Date/Heure [TIMESTAMP ] BLOB [BLOB] Bernard
Wastack committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=21cc1826c758bb71bb0cfa055b3bb51a38bc2acb WiP tdf#74172 use DECIMAL and NUMERIC data types It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi, When I enter a value in a field with type DECIMAL LO crashes. But It seems that it crashes randomly. I am looking for the steps to reproduce. Bernard Version: 5.3.0.0.alpha1+ Build ID: c64b8ffe851d3320a15071fa4bc4b0f12e9939d5 CPU Threads: 2; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; TinderBox: Win-x86@39, Branch:master, Time: 2016-11-11_01:34:42 Locale: fr-FR (fr_FR); Calc: group
Wastack committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a2686cc717187637c47f9c748b115a46bf16eced tdf#74172 ensure prepared while setting numeric It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
No crash with : Version: 5.4.0.0.alpha0+ Build ID: 719f7cb94ce783349fb1cf366a78edd9996d3e37 CPU Threads: 2; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-11-27_03:58:17 Locale: fr-FR (fr_FR); Calc: group
No problem to create a DECIMAL/NUMERIC field. But if I insert any value there (with and without decimal places) the whole LO crashes immediately. Tested with Version: 5.3.0.0.beta1 Build-ID: 690f553ecb3efd19143acbf01f3af4e289e94536 CPU-Threads: 4; BS-Version: Linux 4.1; UI-Render: Standard; VCL: kde4; Layout-Engine: neu; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group on OpenSUSE 42.1 64bit rpm Linux Should I open a new bug for this?
(In reply to robert from comment #18) > No problem to create a DECIMAL/NUMERIC field. But if I insert any value > there (with and without decimal places) the whole LO crashes immediately. > Should I open a new bug for this? Yes, please, especially if it can be reproduced with recent 5.4.0.alpha (nightly) also. Put myself and Tamás/Wastack in CC of the new bug report.
(In reply to Lionel Elie Mamane from comment #19) > (In reply to robert from comment #18) > > No problem to create a DECIMAL/NUMERIC field. But if I insert any value > > there (with and without decimal places) the whole LO crashes immediately. > > > Should I open a new bug for this? > > Yes, please, especially if it can be reproduced with recent 5.4.0.alpha > (nightly) also. Put myself and Tamás/Wastack in CC of the new bug report. Done. The problem aren't the Decimal and Numeric fields. Every update for an existing row is impossible without crash. https://bugs.documentfoundation.org/show_bug.cgi?id=104227