Почему SQL*Loader загрузил 808594481 при использовании типа данных INTEGER?

Я загружал данные с помощью SQL*Loader, и при создании контрольного файла я использовал определение таблицы и случайно оставил тип данных INTEGER в строке «версия».

А в поле «версия» (целочисленный тип данных) вставил значение 808594481.

Мне трудно понять, как он обработал это значение - я предполагаю, что он воспринял его как литерал ... но является ли это суммой ASCII-представлений каждой буквы?

НЕТ!

SELECT ASCII('I')+ascii('N')+ASCII('T')+ASCII('E')+ASCII('G')+ASCII('E')+ASCII('G')+ASCII('E')+ASCII('R') 
  FROM SYS.DUAL

возвращает 666 (что, кстати, весело).

объединить значения ascii?

SELECT ASCII('I')||ascii('N')||ASCII('T')||ASCII('E')||ASCII('G')||ASCII('E')||ASCII('G')||ASCII('E')||ASCII('R') 
  FROM SYS.DUAL

возвращает 737884697169716982

Я надеюсь, что кто-то там знает ответ.

Это фактический управляющий файл:

OPTIONS (SKIP=1)
LOAD DATA
APPEND into table THETABLE
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
(id ,
parent_id ,
record_id ,
version INTEGER,
created_at ,
updated_at ,
created_by ,
updated_by ,
species_and_cohort ,
species_and_cohort_count)

Таблица DDL:

create table THETABLE
(
  id               VARCHAR2(36),
  parent_id        VARCHAR2(36),
  record_id        VARCHAR2(36),
  version                  INTEGER,
  created_at               VARCHAR2(25),
  updated_at               VARCHAR2(25),
  created_by               VARCHAR2(50),
  updated_by               VARCHAR2(50),
  species_and_cohort       VARCHAR2(150),
  species_and_cohort_other VARCHAR2(150),
  species_and_cohort_count NUMBER
)

Данные:

id,parent_id,record_id,version,created_at,updated_at,created_by,updated_by,species_and_cohort,species_and_cohort_other,species_and_cohort_count
60D90F54-C5F2-47AF-951B-27A424EAE8E3,f9fe8a3b-3470-4caf-b0ba-3682a1c79731,f9fe8a3b-3470-4caf-b0ba-3682a1c79731,1,2014-09-23 21:02:54 UTC,2014-09-23 21:02:54 UTC,[email protected],[email protected],"PRCA Cherrylaurel,Sapling","",5
FC6A2120-AA0B-4238-A2F6-A6AEDD9B8202,f9fe8a3b-3470-4caf-b0ba-3682a1c79731,f9fe8a3b-3470-4caf-b0ba-3682a1c79731,1,2014-09-23 21:03:02 UTC,2014-09-23 21:03:02 UTC,[email protected],[email protected],"JUVI Eastern Redcedar,Sapling","",45

oracle sql-loader ctl
person Robert Clayton    schedule 26.09.2014    source источник
comment
Какие данные вы вставляли и каков DDL таблицы (чтобы мы могли попробовать)?   -  person Ben    schedule 26.09.2014
comment
Сделанный. Спасибо за предложение.   -  person Robert Clayton    schedule 26.09.2014

Ответы (1)


arrow_upward
0
arrow_downward

Если вы разделите 808594481 на байты, как это было бы закодировано в 32-битной кодировке дополнения до двух, и обработайте каждый байт как символ в кодировке ascii, вы получите «02,1» или «1,20» в зависимости от порядка байтов. Вы, вероятно, вставили строку, которая начинается или заканчивается одним из них, и какой-то слой между вашим кодом и базой данных незаметно преобразовал ее в целое число.

person recursive    schedule 26.09.2014
comment
значение, которое было в файле .csv, было 1 - person Robert Clayton; 26.09.2014
comment
Я думаю, что ответ заключается в том, что слово INTEGER было закодировано таким образом ... достаточно далеко за пределами обычного рабочего дня, чтобы я мог его принять. Спасибо. - person Robert Clayton; 26.09.2014
comment
Я вижу, что в ваших данных есть последовательность 1,2014-09-23 21:02:54 UTC. Вы уверены, что разделение запятой работает так, как вы предполагали? - person recursive; 26.09.2014
comment
Да, все остальные поля доходят до адресата нормально - person Robert Clayton; 28.09.2014