OCCI - SQL performs >= instead of >

Question

EDIT: Looks the problem is in occi::Number: My bind variable is big number so I am using the biggest occi::Number can get - long double. I made a test and got this problem:

I put 1260365696006 in occi::Number and printed it as (unsigned long) and got 1260365696005 ==> different number!!

Any idea?

 long double ld1 = (long double)1260365696006;
 oracle::occi::Number num2(ld1);
 LOG("num2=%.9Lf num2(unsigned long)=%ld", (long double)num2,   (unsigned long)num2);
                                    
    results are:
    num2=1260365696006.000000000 num2(unsigned long)=1260365696005

Original problem:

I am using occi 21 version on linux. I am running the next query with the max value from the table, so I expect to get no results. But I am getting the row with that value.

select * from CacheMessages where message_id > $message_id_p order by message_id, message_number"

When I run on another table, I get correct results (no results):

select * from Bank where bank_obj_num > $bank_obj_num

What can be the reason/s for '>' to return '>='?

1. There is no rounding issues (all are integer values).
2. Not much records (3500).
3. The parameters for both queries, are type int64 (~ 1,260,364,000,000).
4. This table has a field that is populated by a trigger. (not the 'where' field). The CacheMessages table structure is:

 CREATE TABLE "CACHE_MESSAGES" 
   (    "MESSAGE_OBJ_NUM" NUMBER NOT NULL ENABLE, 
    "MESSAGE_TIME" DATE, 
    "MESSAGE_NUMBER" NUMBER, 
    "MESSAGE_ID" NUMBER, 
    "SERIAL_ID" NUMBER, 
    "MESSAGE" VARCHAR2(4000 CHAR), 
     CONSTRAINT "CACHE_MESSAGES_PK" PRIMARY KEY ("MESSAGE_OBJ_NUM", "MESSAGE_TIME")
  USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 
  STORAGE(
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) LOCAL
 (PARTITION "CACHE_MESSAGES_MAXV" 
  PCTFREE 10 INITRANS 2 MAXTRANS 255 LOGGING 
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "TBS_RNDSAN65" )  ENABLE
   ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 
  STORAGE(
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "TBS_RNDSAN65" 
  PARTITION BY RANGE ("MESSAGE_TIME") 
 (PARTITION "CACHE_MESSAGES_MAXV"  VALUES LESS THAN (MAXVALUE) SEGMENT CREATION IMMEDIATE 
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING 
  STORAGE(INITIAL 8388608 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "TBS_RNDSAN65" ) ;
  CREATE INDEX "CACHE_MESSAGES_IND_01" ON "CACHE_MESSAGES" ("SERIAL_ID") 
  PCTFREE 10 INITRANS 2 MAXTRANS 255 
  STORAGE(
  BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) LOCAL
 (PARTITION "CACHE_MESSAGES_MAXV" 
  PCTFREE 10 INITRANS 2 MAXTRANS 255 LOGGING 
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "TBS_RNDSAN65" ) ;
  CREATE OR REPLACE TRIGGER "CACHE_MESSAGES_SERIAL_TRG" 
BEFORE INSERT OR UPDATE
ON CACHE_MESSAGES
REFERENCING OLD AS OLD NEW AS NEW
FOR EACH ROW
DECLARE
iCounter cache_messages.serial_id%TYPE;
cannot_change_counter EXCEPTION;
BEGIN
IF INSERTING THEN
Select cache_messages_serial_seq.NEXTVAL INTO iCounter FROM Dual;
:new.serial_id := iCounter;
END IF;
IF UPDATING THEN
IF NOT (:new.serial_id = :old.serial_id) THEN
RAISE cannot_change_counter;
END IF;
END IF;
EXCEPTION
WHEN cannot_change_counter THEN
raise_application_error(-20000, 'Cannot Change Counter Value');
END;

Answer 1

Thanks for all. Nothing was relevant :-( I solved my problem by using different type of variable. It was defined as long long (which is not supported by the OCCI), so lucky me, I found that I can use 'long'. It is enough for me (The system was initially was built for 32-but systems). So, now there were no problems to move the right value to the OCCI. BTW, when trying to print the value I sent to OCCI, it returned me 5.999999999 instead of 6 (Which I sent him as long double (OCCI::Number)). Thanks.