Is there an overview of differences between the 2 versions, where also is indicated how exisiting functions in 1.8 have changed in 2.3.3?
Coming from LO with embedded 1.8, moving to split 2.3.3, I am coming accross all kinds of issues, what appears to be differences in between both versions.
Example:
CASE WHEN "tNumber"."Number" <10 THEN '0' ELSE '' END will give result i.e. '08' in version 1.8, while in 2.3.3 it results in ' 08'. There is therefore a space added in front of the result set.
Funtions LEFT, RIGHT, SUSTRING worked in 1.8 alo with Field Type NUMBER, while it appears to be working with Field Type VARCHAR only in 2.3.3.
JD
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We developed a db under LibreOffice embedded 1.8 and are moving the Client to a split database. The version to be used is: 2.3.3. We spent countless hours in developing all the Queries, Forms, and Reports, but moving to 2.3.3, is causing some major headaches. We are trying to pinpoint the differences, where a function in 1.8 is using certain grammar, and what type of grammer is used in the 2.3.3 version. This could be made easier if it was known what the differences are.
The 2nd part, about CASE WHEN, has been solved, however in an example:
CASE WHEN "tNumber"."Number" <10 THEN '0' ELSE '' END || "tNumber"."Number" , where "tNumber"."Number" = '8', the result is ' 08', under 2.3.3., while under 1.8 it was '08'. A space is added, which is undesirable.
JD
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The CASE WHEN difference is caused by the following change:
The type of a string literal was VARCHAR but is now CHARACTER. This means when the empty string is combined with '0' in CASE WHEN and the longest length is used for the result, the empty string becomes a single space.
To override this, cast just one of the string literals to VARCHAR, then all the literals become varchar.
cast('' as varchar(1))
Last edit: Fred Toussi 2015-11-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there an overview of differences between the 2 versions, where also is indicated how exisiting functions in 1.8 have changed in 2.3.3?
Coming from LO with embedded 1.8, moving to split 2.3.3, I am coming accross all kinds of issues, what appears to be differences in between both versions.
Example:
CASE WHEN "tNumber"."Number" <10 THEN '0' ELSE '' END will give result i.e. '08' in version 1.8, while in 2.3.3 it results in ' 08'. There is therefore a space added in front of the result set.
Funtions LEFT, RIGHT, SUSTRING worked in 1.8 alo with Field Type NUMBER, while it appears to be working with Field Type VARCHAR only in 2.3.3.
JD
There is no complete list. Function and query processing in version 2 was written from scratch to conform to SQL Standard.
Regarding the CASE WHEN issue, please provide exact details. Your example cannot return '08'.
We developed a db under LibreOffice embedded 1.8 and are moving the Client to a split database. The version to be used is: 2.3.3. We spent countless hours in developing all the Queries, Forms, and Reports, but moving to 2.3.3, is causing some major headaches. We are trying to pinpoint the differences, where a function in 1.8 is using certain grammar, and what type of grammer is used in the 2.3.3 version. This could be made easier if it was known what the differences are.
The 2nd part, about CASE WHEN, has been solved, however in an example:
CASE WHEN "tNumber"."Number" <10 THEN '0' ELSE '' END || "tNumber"."Number" , where "tNumber"."Number" = '8', the result is ' 08', under 2.3.3., while under 1.8 it was '08'. A space is added, which is undesirable.
JD
The CASE WHEN difference is caused by the following change:
The type of a string literal was VARCHAR but is now CHARACTER. This means when the empty string is combined with '0' in CASE WHEN and the longest length is used for the result, the empty string becomes a single space.
To override this, cast just one of the string literals to VARCHAR, then all the literals become varchar.
cast('' as varchar(1))
Last edit: Fred Toussi 2015-11-23
Also note built-in functions have been extended. In this case:
LPAD("tNumber"."Number", 2, '0')