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

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

Сама задача в дальнейшем была разбита на две подзадача (правильно ли?):
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-ем :).

Изопропил,

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

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

Cat2balalexvнедостаток функциональности DataGridView (классический пример - "условное форматирование" с цветовой схемой) я тоже теоретически в светлом будущем обойду
Без проблем рисуешь что надо в CellPainting или CellFormatting
Классический != единственный, к сожалению :)

igr_ok,

Спасибо, судя по всему - именно то, чего не хватало.