Бьюсь об заклад, проблема в том, что 0x434F4E ... обрабатывается как фактические байты для вставки (0x3078343334463445), а не как шестнадцатеричное расширение. ('0' = 0x30, 'x' = 0x78, '4' = 0x34 и т. Д.) Усечение может произойти, потому что в шестнадцатеричном формате есть два символа на значение, поэтому он пытается вставить строку, вдвое длиннее той, которую вы хотят.
Если вы посмотрите на опции BULK INSERT и не найдете способа интерпретировать hex как двоичный файл, я рекомендую использовать для этого SSIS. У меня нет реального опыта массовой загрузки двоичных значений из SSIS, но, несомненно, он может это сделать, и это будет быстро.
Я думаю, что всегда есть возможность вывести фактические байты двоичных значений, а не шестнадцатеричное их представление, но вы столкнетесь с проблемами, если будете использовать разделитель, поскольку разделитель может быть одним из байты в двоичном значении. Это как раз проблема смешивания текстовых и двоичных данных. Вы могли бы сделать это, используя импорт столбцов фиксированной длины со специальным расширенным синтаксисом для BULK INSERT, который определяет столбцы и их типы данных.