I just tested on my 8.6 Windows/Oracle 12c CSE after manually updating the model id to have 10 digits i.e. 1234567890

When I check the Locks during a checkout using the Detail option I see the same symptoms as you reported i.e. the model id loses the first digit and is visible as 234567890

I suspect this has not been discovered before because it needs a relatively obscure combination of 10 digit model id and either views lock details or using the CSE API. Also it is only impacting reporting and not the actual stored data.

The MODEL_ID column in the DMDL table is defined as NUMBER(10) so it looks like there is some incompatibility with the CSE Client & API being able to handle the final 10th digit. I am think it is possibly something related to the database version/properties.

Could this problem have existed on your Windows Oracle 12c DB prior to moving it to UNIX and you did not notice it? Did you just export/import the DB ?

I just tested on my 8.6 Windows/Oracle 12c CSE after manually updating the model id to have 10 digits i.e. 1234567890

When I check the Locks during a checkout using the Detail option I see the same symptoms as you reported i.e. the model id loses the first digit and is visible as 234567890

I suspect this has not been discovered before because it needs a relatively obscure combination of 10 digit model id and either views lock details or using the CSE API. Also it is only impacting reporting and not the actual stored data.

The MODEL_ID column in the DMDL table is defined as NUMBER(10) so it looks like there is some incompatibility with the CSE Client & API being able to handle the final 10th digit. I am think it is possibly something related to the database version/properties.

Could this problem have existed on your Windows Oracle 12c DB prior to moving it to UNIX and you did not notice it? Did you just export/import the DB ?

We confirmed that the Support Client Model Locks/Detail has a display problem with 10 digit model ID (UI display problem only). Fixing the problem would require changing the model_id from a long to a double which affects pretty much every module & many external action blocks. Due to the potential downstream effects of making that change and the low impact of this pure display problem it was decided that a fix will be deferred at this time.

Further testing by support and Aldred showed no 10 digit limitation/problem with the CSE Ency API.

If you have to enlarge, look at using a 64-bit int - it's very standard these days. For C++, it's intN_t where N is 8,16, 32 or 64 (see <cstdint>). For C, stdint.h.

Having said all that, you still get partial 10 digit numbers already, up to around 2 billion or so (4 if unsigned). So you could still expand the display mask, and it's what would fit with SQL Server, as that's in the DB as a type of int (see https://docs.microsoft.com/en-us/sql/t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql). Given that, you have a bigger problem if you want to expand beyond 2 billion, as you'd have to change the data structure on the CSE for SQL Server by making it a bigint or similar, and it does assume signed.

Am I missing something? A model id can only be in the range 2^31 which can be accommodated in a 32 bit int (and 10 digits, i.e. 2,147,483,648). The issue is purely display, so is this not just a case of needing to ensure that the displayed data in the support client outputs all 10 possible digits rather than 9. It wouldn't have thought it would need a double or long int. If the display is in a Gen GUI client (I think the support client is a Gen application), then the change would be isolated to adding a separate view in the client to display the data which will be passed into the client as an int and then moved to a view of 10 digits. You will need to use a numeric attribute of length 10 (which becomes a C double) since Gen C code will not allow you to use another data type.

However, that said, there are probably higher priority fixes and enhancements to work on...