Tabula:
CREATE TABLE testret(id VARCHAR2(4), data VARCHAR2(4000));
Un tad 4 INSERTi, kas atšķiras tikai ar varchar mainīgā izmēru, bet ne datu garumu.
EXEC SQL BEGIN DECLARE SECTION;
varchar data1333[1333];
varchar data1334[1334];
varchar id1333[1333];
varchar id1334[1334];
EXEC SQL END DECLARE SECTION;
memset(data1333.arr, 'X', 1);
data1333.len = 1;
memset(data1334.arr, 'X', 1);
data1334.len = 1;
id1333.len = 0;
id1334.len = 0;
EXEC SQL INSERT INTO testret (id, data) VALUES ('1', :data1333) RETURNING id INTO :id1333;
assert(SQLCODE == 0);
EXEC SQL INSERT INTO testret (id, data) VALUES ('2', :data1334) RETURNING id INTO :id1333;
assert(SQLCODE == 0);
EXEC SQL INSERT INTO testret (id, data) VALUES ('3', :data1333) RETURNING id INTO :id1334;
assert(SQLCODE == 0);
EXEC SQL INSERT INTO testret (id, data) VALUES ('4', :data1334) RETURNING id INTO :id1334;
assert(SQLCODE == 0);
Izpildot programmu pret Oracle 11.2 serveri UTF-8 kodējumā, kā jums liekas, kāds būs rezultāts šādam vaicājumam?
SELECT id, DECODE(data, NULL, 0, LENGTH(data)) data_length FROM testret;
Nepareizi! Pārsniedzot maģisko izmēru 1333, dati tiek pazaudēti:
ID DATA_LENGTH
---- -----------
1 1
2 1
3 1
4 0
To pašu var uzrakstīt arī ar OCI, nevis PRO*C. Un binārais fails korekti strādā pret vecākām 10.x servera versijām.
Vispār, kopš redzēju kā Oracle 10.2 sajauca vietām kolonas, ja mainīgā izmērs pārsniedza kaut kādus 400x baitus, šajā gadījumā mani pārsteidz tikai maģiskais skaitlis 1333.
