UnixODBC: Decimal formatting problem

Question

UnixODBC: Decimal formatting problem

Navigation

#1 by (3 votes)
#2 by (1 votes)

3

I've set up a server with CentOS 7, SQL Server 2017, and UnixODBC

In tsql, the numbers are correct.

But when I look at isql, the decimals are separated by a comma (,) instead of a period (.).

How can I fix this?

Q: What I really want is to use the number in PHP (you're complaining that the number is having a formatting problem)

UPDATE: The error that appears in PHP is: Notice: A well-formed numeric value encountered in /usr/share/nginx/html/loja3/info_vend/achapeca.php on line 789

I saw now that the error occurs when I use php's number_format

UPDATE 2:

I ran the var_dump and Windows returned: string (12) "3.5000000000" In CentOS: string (3) "3.5"

UPDATE 3:

It seems like the solution is to remove the number_format. But I find it strange because you need the number_format in Windows and not CentOS. Any additional verdicts or tips?

php sql-server odbc centos

asked by anonymous 26.06.2017 / 21:58

2 answers

calculate percentage of iterated items in a loop Separate Letters from a String and Add in a ComboBox

score 3 · Answer 1

It seems like a language definition issue ( language ) in the presentation. For example, in English the decimal point separator is the point and in English it is the comma. Evaluate the behavior of isql by using the -l (locale) option, setting the English language.

In ODBC.ini, verify how LOCALE is configured. Also check the configuration of LC_NUMERIC in Cent OS.

Regarding the value of 40 appears as 23. 99999 ..., this usually occurs with expressions of Floatingpoint ; for example, when the column is declared as float in the database. Depending on how the value is rounded up to be displayed, this difference may occur, as described in Using decimal, float, and real Data : The IEEE 754 specification provides four rounding modes: round to nearest, round up, round down, and round to zero. Microsoft SQL Server uses round up. All are accurate to the guaranteed accuracy but can not result in slightly different floating-point values. Because the binary representation of a floating-point number may use one of many legal rounding schemes, it is impossible to reliably quantify the floating-point value.

EXPANSION :
(1) In isql you can set locale by using the -l option. Details on isql man page .

(2) For information about the Microsoft ODBC driver for CentOS (RHEL clone): Installing the Microsoft ODBC Driver for SQL Server on Linux

(3) Installation instructions for unixODBC, to act as a driver manager in conjunction with the MS ODBC Driver: Installing the Driver Manager

(4) locale definition documentation in PHP: setlocale

score 1 · Answer 2

@ClaudioShigueoWatanabe

I believe it's the same problem I had with a system I developed using an ODBC SQL Server drive. At some point in the ODBC program it does not round the value, I did not find an acceptable explanation for that fact, but I noticed that it had a relationship with the format of the data in the database. Whenever I used the programs to query the database directly the value was correct, when using the system with the ODBC drive had the problem, well had to solve, so create roundings for the cases. Another solution was in all fields that contained decimal values, were put masks to display. To thicken the broth, when performing the insert through the application, the value persisted in the base correctly, but in the recovery of the same screen it appeared with decimals that did not have. I hope you find a solution, with me only changing to ADO, but I did not continue in the project to know if this was actually solved. I developed in Delphi 5 and 7 for MS SqlServer 7 through 2012, the ODBC drive only knew it MSSQLOdbc.