Приветствую!

Возникла задача, озвученная в заголовке. Хотелось бы определиться с подходом, каким образом это делать (на всякий случай, я определенно не спец, посему могу спрашивать какие-то банальные вещи и выражать какие-то опасения, которые на самом деле беспочвенны :)), чтобы потом не было мучительно больно из-за неправильно выбранного.

Сама задача в дальнейшем была разбита на две подзадача (правильно ли?):
1. Загрузить данные из Excel в DataTable. При этом, главный вопрос, который возникает (насколько я понимаю) - каким образом сообщить программе, какие типы данных хранятся в таблице (которая в общем случае неизвестна, но предполагается, что INFORMATION_SCHEMA.COLUMNS, например, доступен), чтобы при генерации DataTable он использовал нужные.
2. Загрузить DataTable в SQL-таблицу.

С пунктом 2 вроде проблем нет, посему в дальнейшем вопрос только по п.1.

Результаты гуглинга выделили три подхода, которые теоретически могут позволить выполнить задачу:
1. через Microsoft.Office.Interop.Excel;
2. через провайдер Microsoft.ACE.OLEDB.12.0 (например);
3. через Open XML.

Дальнейший гуглинг показал:

Минусы первого подхода, в том, что он требует наличия Excel на клиентской машине (что не фатально, но напрягает) + запускает отдельный процесс (какие-нибудь некорректные завершения программы могут оставлять лишние процессы в памяти, предполагаю).

Минусы второго подхода - я так понял, требуют установленной библиотеки на клиентских компьютерах + какие-то проблемы с 64-битными системами и т.п. ( http://social.msdn.microsoft.com/Forums/ru-RU/9b28f96f-f058-4641-9871-ccd3e380a346/-64-microsoftjetoledb40-provider-is-not?forum=fordataru). Решение проблемы вроде как описано, но меня настораживает необходимость менять глобальные настройки проекта (оговорюсь сразу, на что именно они в дальнейшем повлияют - понятия не имею :) ) из-за подключения одной библиотеки (что буду делать, если какая-то другая библиотека потребует обратного переключения, я не очень понимаю).

Минусы третьего подхода - по ощущениям, намного выше "входной порог", по сравнению с первыми (а готового решения не нашел).

Собственно вопрос - правильно ли озвучены минусы и какой подход на самом деле предпочтительнее? При этом, остается задача "сообщить" нужные типы столбцов (кроме как банального switch, на основании данных из INFORMATION_SCHEMA, способа не нашел, на решение как-то не нравится)

VIT2708balalexv,
Excel - DataTable - SqlServer используя SqlBulk
Спасибо за ответ. На всякий случай уточню, SqlBulk мне поможет, насколько я понимаю, только на стадии DataTable -> SqlServer? Если да, то эта стадия мне более-менее вроде понятна, вопрос больше в Excel->DataTable. В принципе, как альтернативный вариант я готов буду рассмотреть вариант изначального сохранения в csv, например (что позволит спокойно пользоваться этой командой, насколько я понял), но сначала хотелось бы рассмотреть варианты с xls/xlsx.

VIT2708А для загрузки из Excel в DataTable вариант 2
Собственно остается вопрос, почему именно вариант 2. Насколько беспочвенны мои опасения, изложенные в "минусы второго подхода"? В частности, нет ли риска, что если я выполню рекомендации msdn:

Проблема в том, что вы компилируете свое решение как “Any CPU”. По умолчанию решение на 64х битной системе будет работать как 64х битный процесс, а оба JET и ACE OLEDB провайдера существуют только в x86 версии. 64х битный процесс не может загрузить x86 компоненты, поэтому и происходит такая ошибка.

, то в дальнейшем это повлечет за собой проблемы?

И что касается требуемой библиотеки - я так понимаю речь о http://support.microsoft.com/kb/239114/ru. Будет ли требоваться устанавливать сей объект на каждом клиентском компьютере?

Спасибо за ответы. Для начала, сделаю несколько оговорок:
1. Интерфейс MS SQL не предполагается доступным пользователю (но запуск созданных процедур на сервере доступен);
2. Задача не только не "разовая", но и решена должна быть в общем случае (то есть и для таблиц с неизвестной заранее структурой, при этом не предполагается "ручками" создавать процедуру для каждой);
3. Создание таблиц не предполагается, предполагается только добавление записей в созданные.

Насколько я понял, реализован SSIS все равно через провайдеры, со всеми присущими этому плюсами и минусами (правильно ли?). Если так, то сходу не могу уловить преимуществ (зато появляется "слабое звено" в виде использования MS SQL - насколько я понимаю, "грубая" реализация через провайдеры позволяет работать с любой СУБД).

Так или иначе, пока все-таки выбрал "подход №2", через провайдеры. Но сомнения, о которых говорил выше, по его поводу, пока остались..

AntonariyНикакого решения "в общем случае" невозможно...
Ну общность решения в любом случае условна - в момент вызова требуемой процедуры по крайней мере название то таблицы известно :). Соответственно, известна и ее структура (с вероятностью, близкой к 100%, ее отдаст любая СУБД). Нет, реализация через провайдеров меня в этом смысле устроила - пока не встретил ситуаций, в которых не смог добавить записи в таблицы, беспокоят лишь ограничения, о которых упоминал.

Antonariybalalexv Соответственно, известна и ее структура (с вероятностью, близкой к 100%, ее отдаст любая СУБД).а какая сущность должна догадаться о правилах разбора произвольных входящих данных в таблицы пусть даже и известной структуры?
Нет, заголовки то столбцов в xls-файле я готов создавать совпадающими с ними же в БД. А отсутствующие столбцы пусть тянутся по значениям по умолчанию/NULL.

Либо, как вариант (собственно и реализованный, через SqlBulk) - просто поддерживается порядок столбцов, совпадающий с таблицей-получателем.

Cat2,

Интерфейс и база имеется, разумеется :). Тем не менее, по опыту в качестве пользователя, так сказать, нередко возникала необходимость загрузить большое количество записей одновременно (в простейшем случае - заполнить какой-нибудь справочник на основании данных "со стороны"). Либо перенос данных, заполненных изначально в Excel (в случаях, если функциональность DataGridView, например, недостаточна - хотя понятно, что сей недостаток теоретически устраним, вопрос времени). Заставлять же пользователей переносить данные из Excel в БД ручками считаю крайне нехорошей практикой (и, к моему удивлению, весьма распространенной).

Понятно, что реально процедура будет юзаться от силы на 5% таблиц, но проще уж один раз универсальную процедуру написать и забыть про нее потом, чем каждый раз писать новую.

AntonariybalalexvЛибо, как вариант (собственно и реализованный, через SqlBulk) - просто поддерживается порядок столбцов, совпадающий с таблицей-получателем.Получается, данные не произвольные, а 1-в-1
В такой реализации - да. В этом смысле мне бы больше понравилась процедура с непосредственным указанием столбцов. Тем не менее, уровень "универсальности" реализации через SqlBulk меня пока что устраивает (хотя и вынуждает добавлять "лишние" столбцы). В любом случае, "общность решения" ведь предполагалась не в произвольной/хаотичной структуре входящего файла, а в том, что одна реализация позволит заполнять в будущем в любые таблицы, не прибегая к коду. Если это не следовало из моих слов ранее, прошу прощения, я большой любитель излишне витиеватых выражений :).

Cat2Использование Excelя - вообще плохая практика
Как очень большой сторонник полной автоматизации всего, что возможно, я вообще считаю наличие пользователей плохой практикой. Тем не менее, пока приходится мириться что с ними, что с используемым ими Excel-ем :).