SqlBulkCopy, не работающий
4 ответа
Ну, действительно ли это правильно? Имена столбцов существуют с обеих сторон?
Честно говоря, я никогда не беспокоился отображениями. Мне нравится сохранять вещи простыми - я склонен иметь таблицу подготовки, которая похожа на вход на сервере, затем я SqlBulkCopy в таблицу подготовки, и наконец выполняет хранимую процедуру для перемещения таблицы от таблицы подготовки в фактическую таблицу; преимущества:
- никакие проблемы с живым повреждением данных, если импорт перестал работать в какой-либо точке
- , я могу поместить транзакцию только вокруг SPROC
- , у меня может быть работа BCP без входа, безопасного в знании, что SPROC будет зарегистрирован
- , это просто;-p (никакое питание с отображениями)
Как последняя мысль - если Вы имеете дело с объемными данными, можно получить лучшую пропускную способность с помощью IDataReader (так как это - потоковый API, тогда как DataTable буферизированный API). Например, я склонен сцеплять импорт CSV с помощью CsvReader в качестве источника для SqlBulkCopy. С другой стороны, я записал контейнеры приблизительно XmlReader для представления каждого элемента первого уровня как строку в IDataReader - очень быстро.
Ответ Marc был бы моей рекомендацией (при использовании таблицы подготовки). Это гарантирует, что, если Ваш источник не изменяется, у Вас будет меньше импорта проблем в будущем.
Однако, по моему опыту, можно проверить следующие проблемы:
Имена столбцов соответствуют в источнике и таблице, Которой типы столбца соответствуют
, Если Вы думаете, что сделали это и все еще никакой успех. Можно попробовать следующее.
1 - Позволяют, аннулирует во всех столбцах в Вашей таблице 2 - комментируют все отображения столбца 3 - повторно выполненный добавляющий один столбец за один раз, пока Вы не находите, где Ваша проблема
, Который должен произвести ошибку
What I have found is that the columns in the table and the columns in the input must at least match. You can have more columns in the table and the input will still load. If you have less you'll receive the error.
Я столкнулся с той же проблемой при копировании данных из доступа к SQLSERVER 2005 и обнаружил, что сопоставления столбцов чувствительны к регистру в обоих источниках данных независимо от чувствительности баз данных.