Recently we moved our gen cse DB from windows oracle to unix oracle (both v12).
What I noticed is that the support client is now reporting just a 9 digit model id instead of 10 digits when viewing model locks.
Also, the cse api is also reporting the same issue - dropping off the first numeric. (ie model id 2052427376 is reported as 52427376 as the zero is also dropped)
I checked the DB via sql_developer (and sqlplus) and the model id is reporting correctly(2052427376)
This is for any model id that has 10 numbers ... 9 and below are reporting back ok.
Anyone seen this before?
I have the odbc with the right 'workarounds' for number to float. NLS_LANG is set to AMERICAN_AMERICA.AL32UTF8
thanks for your insights!
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 ?
Please raise a support case and we will investigate it further.
thanks for the check Lynn ... I'll raise a support case.
During further testing I also recreated with 8.6 SQL Server CSE, so root cause appears to be DB/DB platform independent.
So am I thinking this problem may have always existed but previously went unnoticed. I have now passed on to Engineering via your support case.
.... and after checking the docops all the CSE API functions reference model id (nModelId) with value 9 so that would also explain the behaviour with the API e.g.
I think value 9 refers to the value passed to the modelId not the length of the variable (so same as 1234567890 in your example).
in the encyapi.h MODELIDis defined as long, which should have the 10 digit resolution according to the MS Data Type Ranges for VS2010
(here is defn from encyapi.h)
typedef long MODELID;
So, I guess there is still an issue ...
Thanks Aldred - agreed
For the benefit of the community:
Lynn, do yourself a favour - never, ever look at using a double. It's a lesson I've learnt the hard way (it'll kill Oracle performance if you write Gen code assuming num 10, fwiw).
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...