Задача, на первый взгляд, самая что ни на есть простая: есть база MSSQL, есть некий сервер приложений, есть файл Excel, который нужно передать на сервер, сохранить копию, пропарсить и залить в таблицы MSSQL.
Файл Excel представляет собой обычный прайс — матрицу примерно 5000 * 10 записей.
Несмотря на богатый выбор технологий, предлагаемых MS для решения задачи, при близком рассмотрении оказывается, что все они в той или иной степени недостаточно надёжные по причинам известной недетерминированности структуры листа Excel: на листе, кроме таблицы, может присутствовать "шапка" и "подвал"; пользователь может забыть типизировать ячейку и вколотить в числовое поле строку; в саму табличную часть документа пользователь может для красоты добавлять пустые строки и т.д.
Имеющиеся в наличии инструменты:
1) Excel + Linked Server/Opernrowset — эта связка заведомо не будет работать при заведомо нетабличной структуре обрабатываемого листа Excel
2) Excel + Integration Services — то же самое
3) Обработка входящего файла на сервере приложений через VBA или Office Interop — чрезвычайно трудоёмко
4) Интеграция с .NET посредством Visual Studio Office Project — ?
5) Прямое обращение к MSSQL через Excel VBA — ?
6) Взаимодействие с веб-сервисом из Excel (c использованием SOAP Toolkit или при помощи интеграции с .NET) — ?
Кроме того. Взаимодействие с Excel желательно сделать двусторонним, то есть, к примеру, предоставить пользователю возможность автоматической синхронизации справочника номенклатуры, хранящегося на сервере MSSQL.
Есть ещё возможность прикрутить к этому всему хозяйству SharePoint Services, но пока даже не могу предположить, каким боком.
Здравствуйте, baranovda, Вы писали:
B>5) Прямое обращение к MSSQL через Excel VBA — ? B>6) Взаимодействие с веб-сервисом из Excel (c использованием SOAP Toolkit или при помощи интеграции с .NET) — ?
Я бы выбрал одно из этих двух (только без интеграции с NET). К сожалению, за вгрузку NET в офис приходится расплачиваться лишними секунд 20-30 загрузкой Excel(то же самое касается всех продуктов Office, IE и возможно еще что-то). Посему лучше прямой ADO(благо его не отменяли) и SOAP Toolkit. Ессно выбор благодаря трем вопросам: секьюрити прямого доступа к MSSQL, сложность преобразований данных перед передачей в БД и сценарий изменения логики при развитии проекта. Ежели проблем нет, то лучше прямой доступ, благо писанины немного.
Здравствуйте, baranovda, Вы писали:
B>Задача, на первый взгляд, самая что ни на есть простая: есть база MSSQL, есть некий сервер приложений, есть файл Excel, который нужно передать на сервер, сохранить копию, пропарсить и залить в таблицы MSSQL.
B>Файл Excel представляет собой обычный прайс — матрицу примерно 5000 * 10 записей.
B>Несмотря на богатый выбор технологий, предлагаемых MS для решения задачи, при близком рассмотрении оказывается, что все они в той или иной степени недостаточно надёжные по причинам известной недетерминированности структуры листа Excel: на листе, кроме таблицы, может присутствовать "шапка" и "подвал"; пользователь может забыть типизировать ячейку и вколотить в числовое поле строку; в саму табличную часть документа пользователь может для красоты добавлять пустые строки и т.д.
B>Имеющиеся в наличии инструменты: B>1) Excel + Linked Server/Opernrowset — эта связка заведомо не будет работать при заведомо нетабличной структуре обрабатываемого листа Excel B>2) Excel + Integration Services — то же самое B>3) Обработка входящего файла на сервере приложений через VBA или Office Interop — чрезвычайно трудоёмко B>4) Интеграция с .NET посредством Visual Studio Office Project — ? B>5) Прямое обращение к MSSQL через Excel VBA — ? B>6) Взаимодействие с веб-сервисом из Excel (c использованием SOAP Toolkit или при помощи интеграции с .NET) — ?
B>Кроме того. Взаимодействие с Excel желательно сделать двусторонним, то есть, к примеру, предоставить пользователю возможность автоматической синхронизации справочника номенклатуры, хранящегося на сервере MSSQL.
B>Есть ещё возможность прикрутить к этому всему хозяйству SharePoint Services, но пока даже не могу предположить, каким боком.
B>В общем, прошу поделиться опытом.
Если Excel 2007, то то можно так:
1)Окрываете excel, на вкладке "данные" в группе "получить внешние данные" создаете подключение к БД (Из других источников -> SQL сервер).
2)на странице появляется таблица, которая по желанию и\или с определенным интервалом подсасывает данные из базы.
3)Ставите OpenXML SDK v2, с помощью него можно на сервере парсить xslx документ и вытянуть нужные значения ячеек таблицы, которые можно сохранить в БД.
4)Останется только геморрой с валидацией данных.
5)При желании серверный код запиихвается в event receiver библиотеки документов WSS и сами xslx файлы для разных талиц туда укладываются.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, baranovda, Вы писали:
B>>5) Прямое обращение к MSSQL через Excel VBA — ? B>>6) Взаимодействие с веб-сервисом из Excel (c использованием SOAP Toolkit или при помощи интеграции с .NET) — ? GZ>Я бы выбрал одно из этих двух (только без интеграции с NET). К сожалению, за вгрузку NET в офис приходится расплачиваться лишними секунд 20-30 загрузкой Excel(то же самое касается всех продуктов Office, IE и возможно еще что-то).
Особых тормозов не заметил (1-4 задержки секунды максимум), но бесит то, что, например, в проекте Office Workbook можно создать только один Workbook. Соответственно, для десятка всевозможных типов входных документов нужно делать десять отдельных проектов.
GZ>Посему лучше прямой ADO(благо его не отменяли) и SOAP Toolkit. Ессно выбор благодаря трем вопросам: секьюрити прямого доступа к MSSQL, сложность преобразований данных перед передачей в БД и сценарий изменения логики при развитии проекта. Ежели проблем нет, то лучше прямой доступ, благо писанины немного.
Здравствуйте, baranovda, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>Если Excel 2007, то то можно так:
B>Не, к сожалению только 2003.
У меня есть подозрение, что разработка решения для 2003, удовлетворяющего всем приведенным требованиям, и поддержка его выйдет дороже покупки пачки лицензий для 2007 офиса.
Если по условиям задачи формат данных может быть не вполне формальным и особенно если необходимо не просто пропускать "неформат", а пытаться компенсировать типичные ошибки, то никакого другого выхода, кроме ручного ковыряния в файле, я не вижу даже в теории.
Другое дело, что я бы предложил не драматизировать сложность такого решения. Мне как-то пришлось решать задачу по поиску в файлах excel-я некоторых ячеек по весьма мутным признакам, распознаванию даты вбитой "где-то тут", "рядом с вот этим вот или прямо тут, через пробел" в совершенно произвольном формате, часто с ошибками в написании месяца и т.п.
Здравствуйте, gandjustas, Вы писали:
G>У меня есть подозрение, что разработка решения для 2003, удовлетворяющего всем приведенным требованиям, и поддержка его выйдет дороже покупки пачки лицензий для 2007 офиса.
Не думаю... Написание скрипта и сгон собранных данных через ADO, при наличии минимума знаний — 1 ч/д. Так что в данном случае, крутизна — не есть показатель трудоемкости. Правда про деплоинг — вопроса не было...
Я за этот способ. Единственное, что предлагаю разработать функционал в виде надстройки к Excel. Таблицы парсятся замечательно если использовать автоматы для синтаксического анализа. Сам реализовывал двухуровневый автомат, когда каждая строка — таблица.
Можно упростить себе жизнь попросив пользователя выделить область для анализа и дать ей название (тоже можно сделать через надстройку).
(скриншоты не понял как вставить)
