Любые идеи о том, как я могу заполнить BOUNDFILLER из таблицы поиска?
Вы не можете.(Несмотря на то, что формулировка в документации предполагает, что вы должны быть в состоянии; я думаю, что это ошибка с документом, и она должна сказать что-то вроде «Заполняющие поля не могут быть указаны как часть строки SQL спецификации другого поля, потому что ...» -и тогда исключение для BOUNDFILELR имеет больше смысла).
Если EMPID не является полем в вашем файле данных, тогда вам не нужен заполнитель для него.Если он находится в файле, но отсутствует в целевой таблице, вы можете пропустить его с простым FILLER, если только вы не захотите обратиться к этому значению файла позже.Если это столбец в вашей целевой таблице, вы могли бы вместо этого использовать поиск EXPRESSION, но тогда вы не можете ссылаться на него как на переменную связывания в другом месте.
Если вы хотитечтобы ссылаться на него в других выражениях SQL для других столбцов в вашем управляющем файле, вам потребуется повторить поиск в качестве подзапроса в них.
Например, у вас может быть:
REFNBR BOUNDFILLER,
EMPID EXPRESSION "(SELECT EMPID FROM lookuptable WHERE REFNBR = :REFNBR)",
EMPFIRSTNAME EXPRESSION "(SELECT FIRST_NAME FROM anothertable WHERE empid = (SELECT EMPID FROM lookuptable WHERE REFNO = :REFNBR))",
...
или немного с объединением:
REFNBR BOUNDFILLER,
EMPID EXPRESSION "(SELECT EMPID FROM lookuptable WHERE REFNBR = :REFNBR)",
EMPFIRSTNAME EXPRESSION "(SELECT t1.FIRST_NAME FROM lookuptable t1 JOIN anothertable t2 ON t2.empid = t1.empid WHERE t1.REFNBR = :REFNBR)",
...
Я объявил их как EXPRESSION при условии, что у них нет соответствующих полей в файле данных - в основном для этих целей, что файл данныхтолько имеет REFNBR.(У вас могут быть другие поля, которые вы не показали; у вас могут даже быть поля, соответствующие EMPID и т. Д., Которые вы игнорируете - но в этом случае я бы обработал их как FILLER и в любом случае имел бы независимые EXPRESSION записи для созданияясно, что они не связаны.)
Чего вы не можете сделать, так это либо предоставить выражение SQL как часть BOUNDFILLER, либо сослаться на один EXPRESSION в выражении SQL другого поля, то есть:
REFNBR BOUNDFILLER,
EMPID EXPRESSION "(SELECT EMPID FROM lookuptable WHERE REFNBR = :REFNBR)",
EMPFIRSTNAME EXPRESSION "(SELECT FIRST_NAME FROM anothertable WHERE empid= :EMPID)",
...
, поскольку это приведет к выдаче
SQL * Loader-291: неверная переменная привязки EMPID в строке SQL для столбца EMPFIRSTNAME.
Причина одинакова для обоих. Из документации :
Для каждого чтения входной записи значение поля, на которое ссылается переменная связывания, будет заменено на переменную связывания.
Он просматривает значение поля из файла , а не после какого-либо преобразования образует выражение SQL.Если вы использовали только REFNBR для этого поиска, вы могли бы не ссылаться на это непосредственно и делать:
EMPID "(SELECT EMPID FROM lookuptable WHERE REFNBR = :EMPID)",
EMPFIRSTNAME EXPRESSION "(SELECT FIRST_NAME FROM anothertable WHERE empid= :EMPID)",
...
, но в оценке EXPRESSION он все еще использует исходное значение значения изфайл - то есть фактически REFBNR - а не окончательное значение, которое будет вставлено как EMPID.Поэтому не найдет совпадения или не найдет нужную вам строку, что, вероятно, еще хуже.
Учитывая это, для BOUNDFILLER не имеет смысла разрешать использование выражения SQL- результат этого выражения никогда не будет использоваться.
Несколько других мыслей ... Ясно, что повторение подзапроса / соединения является грязным, поэтому я понимаю, почему измененное значение многократного использования было бы полезно вэтот сценарий.Но так как вы не можете сделать это, было бы проще загрузить необработанные REFNBR (и любые другие необходимые вам поля из файла) в промежуточную таблицу - либо физическую, либо внешнюю таблицу, как предложено @Littlefoot, - и затем выполнить запросэто и присоединиться к другим таблицам, чтобы сделать последнюю вставку в вашу целевую таблицу.
И это выглядит - из того, что может быть очень надуманным примером - как вы дублируете данные, что может быть нецелесообразно;может быть, лучше на самом деле просто иметь REFNBR или хотя бы просто EMPID в вашей целевой таблице вместо ссылочных ограничений, поэтому любые изменения, сделанные в anothertable, отражаются автоматически при запросе.Это может быть частью более крупного процесса, который архивирует и удаляет, или что-то еще;но тогда было бы проще использовать промежуточную / внешнюю таблицу и исключить весь этот процесс, вместо того, чтобы заставлять SQL * Loader выполнять часть этой работы.