Dealing with BIG INT 

Dealing with BIG INT 

An integer in the agile platform is declared as a int32 therefore it has a range of  -2147483647 to +2147483647.

Now if you used an external database with a BIG int primary key, it has a range of -2^63 (-9,223,372,036,854,775,808) to 2^63-1 (9,223,372,036,854,775,807).

Now you import your database table, and your table are using a bigint as the primary key, you map this table using intergration studio. By default integeration studio will mapped the bigint datatype column to an integer datatype, and evenutally in time, your database record will exceed 

Now how will you avoid this issue and stop it from overflowing?
SUCCESS: After further testing it was found that we are able to a support "bigint" datatype primary key via an external database, by mapping the bigint primary key to a "text" datatype. 


First we created a sample SQL Server test database table, that we used in our test below.
Id (bigint) Primary key
Name ((varchar(50))
Description ((varchar(100))

TEST #1:
We created an extension for our external database
1) We used integration studio to import the database table (here we mapped the sample database table with bigint primary key datatype as integer datatype)
2) Created an application using the imported database
3) Created a new record entry, verification. Success!
4) Editted the new record entry, verification. Success!

Test: Success.
TEST #2:
After test 1, we attempted to change the primary key Id from int to decimal (19,0) 
We were unable to succesfully publish the extension
ERROR: "Invalid Extension Implementation: "The property 'ssId' in the struct 'Outsystems.NssMyTestDB.ENCompanyEntityRecord" should be of type 'System.Decimal' instead of 'System.Int32'.

Test: Failed.
(This test failed because the generated code is using the previous declaration of Id as an interger)
TEST #3:
We created a new extension, and imported the external database again, this time we changed the default primary key from int to decimal (19,0) but found that we were unable to set our decimal attribute to a primary key (ie Set as Identifier).
Test: Failed.

TEST #4:
We created a new extension, and imported the external database a 3rd time, this time we changed the default primary key from int to text and published the extension.  Success!
Next we opened the previous application created in TEST #1, and updated our code.
We verified that we are still able to retrieve our previous records created in TEST #1: step 3, by viewing the records via the listing web screen. Success all records previously created are properly listed.
-We create a new record entry, Success!
-Edit the new record entry, Success!

Test: Success.

Note: You might be able to get data in and out but its probably not the ideal or practical way to solve the bigint problem. 
Hi Robert,

Great post, thanks for sharing - as you said it's not the ideal solution, but it's a pretty smart workaround that might come very handy.

Tiago Simões