Working with the BigInt Type in Node and SQL Server

Your applications can interact with SQL Server in several different ways and from different platforms. When the public preview of SQL Server running on linux is released, it seems that the possibilities will be even greater. Microsoft is making sure that SQL Server will work on just about any current platform. This is not the same old SQL Server you’re familiar with anymore.

It is not just the choice of server platform that is changing, but also the way of accessing it. From this Microsoft announcement , SQL Server has official support for Node. This got me thinking, “what are the caveats?” Coming from the culture of a run-of-the-mill .NET shop with a SQL Server backend, I decided to investigate. javascript, after all, is ubiquitous; it runs on every platform, and Node has a workable alternative for SQL Server.

Whatever you use to make a connection to SQL Server, whether SSMS, ODBC or JDBC, you will do it via the Tabular Data Stream (TDS) protocol. This was originally devised by Sybase in 1984 as a layer over TCP/IP for communicating with relational databases. The team at Microsoft decided to continue to use this same protocol to interact with SQL Server. There is a JavaScript implementation of this protocol, written as a Node package, called Tedious , that allows you to access SQL Server directly without using ODBC under the hood as Azure/node-sqlserver does. Tedious supports transactions , Table-Valued parameters, and bulk load , so it’s production ready. Tedious is a JavaScript implementation for the Node environment, it does not use ODBC or JDBC.

Tedious supports the SQL Server data types, including BigInt. Most of you would know about the implications of data types from working with SQL Server tables. But, what about Node? The Node environment runs JavaScript, and the native data types in JavaScript are inevitably different. This will have repercussions unless you are aware of how to deal with this difficulty. Well, time to explore those implications.

What is a BigInt?

The BigInt data type in SQL Server is the 64-bit representation of an integer. It takes up 8 bytes of storage. It can range from -2^63 (-9,223,372,036,854,775,808) to 2^63 (9,223,372,036,854,775,807). Two raised to the power of sixty-three is about nine quintillion , a very big number. Imagine a number greater than the number of grains of sand on Earth , it is this big.

BigInt types in SQL Server are useful for the primary key in very large tables. In my own experience, I have used them as the primary key for an authentication audit table. The BigInt was used for the audit id that was used for session data in case authentication failed.

SQL Server likes indexes that are narrow, and predictable. A sequential integer type as a primary key is good in the type of table where all you insert new rows, but don’t delete them, because this reduces index fragmentation.

Create a SQL Table with BigInt

We need to illustrate the problems of passing a BigInt between JavaScript and SQL Server, so it is time to get our hands dirty with SQL Server. We’ll use the BigIntInNodeTest table in the FunWithBigIntInNode database throughout this article.

First create this sample database and table:

CREATE DATABASE FunWithBigIntInNode; GO USE FunWithBigIntInNode; GO CREATE TABLE dbo.BigIntInNodeTest( Id BIGINT NOT NULL, IsAtMax BIT NOT NULL, CONSTRAINT PK_BigIntInNodeTest_Id PRIMARY KEY(Id)); GO INSERT INTO dbo.BigIntInNodeTest(Id, IsAtMax) VALUES (1, 0), (9223372036854775807, 1); GO

This table has a primary key called Id that is of BigInt type. The IsAtMax Bit type tells me whether the BigInt has hit the limit. I have inserted two values in the test table, one at 1 and one at the limit.

The T-SQL above tells you where this table comes from, so you don’t get lost.

Stored Procedure

In my Node applications, I like to separate the Node code from T-SQL, so as to get a lean-and-mean data access layer. Tedious can execute parameterized stored procedures on SQL Server.

I’ll create two stored procedures with two separate concerns. One reads data from the table and one writes data to it.

CREATE PROCEDURE dbo.GetBigIntById( @Id BIGINT ) AS SELECT Id, IsAtMax FROM dbo.BigIntInNodeTest WHERE Id = @Id; GO CREATE PROCEDURE dbo.InsertBigInt( @Id BIGINT, @IsAtMax BIT ) AS INSERT INTO dbo.BigIntInNodeTest(Id, IsAtMax) VALUES (@Id, @IsAtMax); GO

This will help me to keep the Node data access layer nice and clean.

Read and Write Data

With the table in place in SQL Server, we can now script the data access layer in Node. Remember I inserted two rows in dbo.BigIntInNodeTest, one with a value of 1 and one with the BigInt limit. I’ll use these values to query for data using the stored procedure.

To query for the value 1 using Node:

var Connection = require('tedious').Connection; var Request = require('tedious').Request; var TYPES = require('tedious').TYPES; var config = require('./sqlConfig'); var connection = new Connection(config); var requestBigInt = new Request('dbo.GetBigIntById', function onRequest(err, rowCount) { if (err) { console.error(err); } if (rowCount === 0) { console.log('No rows found.'); connection.close(); } }); requestBigInt.addParameter('Id', TYPES.BigInt, 1); requestBigInt.on('row', function onRow(columns) { console.log(columns); connection.close(); }); connection.on('connect', function onConnect() { connection.callProcedure(requestBigInt); });

This gives you a working connection to SQL Server. The API is event-driven with asynchronous behavior. The onConnect callback, for example, fires after the initial connection establishes. This callback then calls a procedure using the request object. Tedious follows the same conventions as other Node APIs that come out of the box in the core library. The key is to know that asynchronous behavior uses humble callbacks in Node.

The sqlConfig file is a JSON configuration file that has connection information:

{ "userName": "username", "password": "password", "server": "server", "options": { "database": "FunWithBigIntInNode", "encrypt": true } }

When you run this query in Node, it gives you the correct data set in columns. You get a ‘1’ back in the Id column which is what’s expected. This means that we can query for BigInt using plain old vanilla JavaScript numbers. Everything is going well so far.

Out of curiosity, we then put the BigInt limit in the parameter, for example:

requestBigInt.addParameter('Id', TYPES.BigInt, 9223372036854775807); We will expect a row back, the other one w