Bigint columns are being returned as strings
See original GitHub issueWhen querying a bigint column the result is coming back as a string. Quick example:
CREATE TABLE test (
col_bigint bigint,
col_int int,
col_smallint smallint,
col_tinyint tinyint,
col_float float,
col_decimal decimal(9,4)
);
Running the query select * from test returns:
[ { col_bigint: '1',
col_int: 1,
col_smallint: 1,
col_tinyint: 1,
col_float: 1.11,
col_decimal: 1.11 } ]
This is against Azure SQL Database V12. Have not tested other versions of SQL Server.
Issue Analytics
- State:
- Created 8 years ago
- Comments:7
Top Results From Across the Web
pg-promise returns integers as strings - node.js - Stack Overflow
bigint is 64-bit, and all 64-bit integers are returned by the underlying node-postgres driver as type string , while 32-bit ones are ...
Read more >PHP :: Bug #73396 :: bigint columns are returned as strings
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!...
Read more >Schema Builder | Knex.js
In MySQL or PostgreSQL, adds a bigint column, otherwise adds a normal integer. Note that bigint data is returned as a string in...
Read more >STRING_SPLIT (Transact-SQL) - SQL Server - Microsoft Learn
The return type is bigint. Remarks. STRING_SPLIT inputs a string that has delimited substrings and inputs one character to use as the delimiter...
Read more >11.1.1 Numeric Data Type Syntax - MySQL :: Developer Zone
You can always store an exact integer value in a BIGINT column by storing it using a string. In this case, MySQL performs...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

@jtmilne Because of the nature of JS numbers, you can’t really tell without extra computation of a bigint will fit in the safe integer space (52-bits) of a 64-bit floating point number… If you need something you can do calculations against you can use bignum or another npm module for dealing with the larger numbers… If you know you aren’t going to exceed 52-bits, you can coerce the value via parseInt(value,10) for those fields… don’t use bitwise coersions (~~value will give you a 32bit number)… prefer parseInt(x,10), or +value … Also, make sure to compare against Number.MAX_SAFE_INTEGER and MIN_SAFE_INTEGER before using said number as an integer… not to mention bounds checking any computed results.
Makes sense. In my case I am just reading a bigint from one table and using it as a parameter for other queries (insert, update, select) so I am not concerned of the integrity of the source number.
Thanks.