Использование Excel в качестве внешнего интерфейса для доступа к базе данных (с VBA) - PullRequest
27 голосов
/ 10 марта 2009

Я создаю небольшое приложение для друзей, и они хотели бы иметь возможность использовать Excel в качестве внешнего интерфейса. (пользовательский интерфейс в основном будет пользовательской формы в Excel). У них есть куча данных в Excel, которые они хотели бы запросить, но я не хочу использовать Excel в качестве базы данных, так как не думаю, что она подходит для этой цели и рассматриваю возможность использования Access. [Кстати, я знаю, что у Access есть свои недостатки, но бюджет нулевой и Access уже на компьютере друга]

Подводя итог, я рассматриваю возможность выгрузки группы данных в Access и последующего использования Excel в качестве внешнего интерфейса для запроса базы данных и отображения результатов в среде стиля пользовательской формы.

Вопросы:

  1. Насколько просто связать Access из Excel с помощью ADO / DAO? Это довольно ограничено с точки зрения функциональности или я могу стать креативным?
  2. Оплачиваю ли я штраф за производительность (по сравнению с использованием форм в Access в качестве пользовательского интерфейса)?
  3. Предполагается, что база данных всегда будет обновляться с помощью команд ADO / DAO из Excel VBA. Означает ли это, что у меня может быть несколько пользователей Excel, использующих эту единую базу данных Access, и не будет возникать проблем с параллелизмом и т. Д .?
  4. Любые другие вещи, о которых я должен знать?

Я обладаю сильными навыками Excel VBA и думаю, что смогу довольно быстро преодолеть Access VBA, но никогда прежде не делал ссылки на Excel / Access. Я мог бы вставить данные в Excel и использовать в качестве квази-базы данных, но это кажется более болезненным, чем оно стоит (а не надежным долгосрочным решением)

Любой совет приветствуется.

Alex

Ответы [ 12 ]

41 голосов
/ 10 марта 2009

Я уверен, что вы получите массу ответов "не делай этого", и я должен сказать, что на это есть веская причина. Это не идеальное решение ....

При этом я и раньше шел этим путем (и аналогичными), главным образом потому, что работа определяла его как жесткое требование, и я не мог обойти его.

Вот несколько вещей, которые следует учитывать при этом:

Насколько просто связать Access из Excel с помощью ADO / DAO? Это довольно ограничено с точки зрения функциональности или я могу стать креативным?

Это довольно смиренно. Вы более ограничены, чем если бы вы делали что-то, используя другие инструменты, поскольку формы VBA и Excel немного более ограничивают, чем большинство полноценных языков программирования, но нет ничего, что могло бы стать препятствием для показа. Это работает - иногда это немного уродливо, но это работает. В моей последней компании мне часто приходилось делать это, и иногда я получал данные из Access и Oracle через VBA в Excel.

Оплачиваю ли я штраф за производительность (по сравнению с использованием форм в Access в качестве пользовательского интерфейса)?

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

В моем случае самым медленным (и самым болезненным) делом была попытка заполнить электронные таблицы Excel на основе данных Access. Это было не весело, и часто было очень медленно. Если вам нужно пойти по этому пути, обязательно сделайте все с Excel скрытым / невидимым, иначе перерисовка вас убьет.

Предполагается, что база данных всегда будет обновляться с помощью команд ADO / DAO из Excel VBA. Означает ли это, что у меня может быть несколько пользователей Excel, использующих эту единую базу данных Access, и не будет возникать проблем с параллелизмом и т. Д .?

Вы в значительной степени используете Excel в качестве клиента - так же, как вы используете приложение WinForms или любой другой инструмент. Клиенты ADO / DAO для Access довольно хороши, так что вы, вероятно, не столкнетесь с проблемами параллелизма.

Как говорится, Access НЕ масштабируется хорошо. Это прекрасно работает, если у вас есть 2 или 3 (или даже 10) пользователей. Если у вас будет 100, вы, вероятно, столкнетесь с проблемами. Кроме того, я обнаружил, что Access нуждается в регулярном обслуживании, чтобы не было проблем с коррупцией. Регулярное резервное копирование БД Access является обязательным. По моему опыту, регулярное сжатие базы данных поможет предотвратить повреждение базы данных.

Любые другие вещи, о которых я должен знать?

Вы делаете это трудным путем. Использование Excel для доступа к Access будет гораздо более трудоемким, чем просто использование Access напрямую.

Я бы порекомендовал изучить API Access VBA - большинство из них такое же, как в Excel, поэтому у вас будет небольшая кривая обучения. Части, которые отличаются, просто делают это легче. Вы также получите все преимущества отчетов и форм Access, которые намного более ориентированы на данные, чем в Excel. Отчеты могут быть полезны для подобных вещей, а наличие макросов и отчетов облегчит жизнь в долгосрочной перспективе. Если пользователь будет использовать формы для управления всем, выполнение форм в Access будет очень и очень похоже на их выполнение в Excel и будет выглядеть почти идентично, но сделает все быстрее и плавнее.

15 голосов
/ 10 марта 2009

Я делаю это все время. Если вы используете ADO, вы на самом деле используете не Access, а Jet, базовую базу данных. Это означает, что любое приложение с Excel может использовать приложение - доступ не требуется. О, я должен упомянуть, место, где я работаю, купило кучу лицензий Office Small Business - без доступа. Прежде чем работать здесь, я бы предположил, что любой, кто имел Excel, также будет иметь доступ. Не так.

Я создаю один класс для каждой таблицы в Access. Я очень редко выполняю запросы через ADO, вместо этого я сохраняю эту логику в модулях класса. Я прочитал инструкцию SELECT и выполнил команду UPDATE или INSERT, используя метод Execute объекта ADODB.Connection.

См. http://www.dailydoseofexcel.com/archives/2008/12/21/vba-framework-ii/

если вы хотите посмотреть, как я настроил свой код.

Чтобы ответить на ваши вопросы: если вы уже знакомы с Excel VBA, это будет небольшой кривой обучения, но вам придется кое-чему научиться; вы заплатите штраф за производительность за выполнение всего этого в Access, но это не так уж плохо, и только вы можете решить, стоит ли это того; и вы можете иметь несколько человек, имеющих доступ к базе данных.

9 голосов
/ 10 марта 2009

Просто пропустите часть Excel - пользовательские формы Excel - это всего лишь плохая версия того, как более надежные формы доступа. Кроме того, Access VBA идентичен Excel VBA - вам просто нужно изучить объектную модель Access. С простым приложением вам в любом случае не нужно будет писать много VBA, потому что в Access вы можете легко соединить все вместе.

8 голосов
/ 10 марта 2009

Если у конечного пользователя есть Access, может быть проще разработать все это в Access. В Access встроены некоторые инструменты для разработки форм WYSIWYG.

7 голосов
/ 10 марта 2009

Если нет сильного преимущества при запуске вашей пользовательской формы в Excel, тогда я бы выбрал решение 100% Access, которое экспортировало бы отчеты и данные в Excel на специальной основе.

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

Что касается ваших вопросов:

  1. Очень просто. На эту тему были некоторые другие вопросы по SO.
    Например, этот и этот .

  2. Не знаю, но я предполагаю, что может быть небольшой штраф.
    Самая большая трудность, которую я вижу, - это попытаться получить все функциональные возможности, которые предоставляет вам Access, и заново создать некоторые из них в Excel.

  3. Да, у вас может быть несколько пользователей Excel и одна база данных Access.
    Здесь снова использование Access в качестве внешнего интерфейса и хранение данных в связанной базе данных Access в вашей сети будет более разумным, и это просто, как пирог, в Access даже есть мастер, который поможет вам сделать это: это всего лишь 1 щелкните прочь .

На самом деле, как и говорили многие другие, потратить немного времени на ознакомление с Access, это сэкономит вам много времени и хлопот.
Возможно, вы лучше знаете Excel, но если вы уже прошли 80% пути, если вы знаете VBA и знакомы с объектной моделью Office.

Другие преимущества выполнения в Access: Access 2007 является бесплатным , что означает, что если вы развернете приложение на 1 или 30 ПК, это будет стоить вам столько же: ничто .
Для разработки вам нужна только одна полная версия Access (у Runtime нет дизайнеров).

3 голосов
/ 18 марта 2009

Это действительно зависит от приложения. Для обычного проекта я бы порекомендовал использовать только Access, но иногда потребности специфичны, и электронная таблица Excel может быть более подходящей.

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

Поскольку в форме использовалось многозначное сжатие, было разумнее создавать ее в Excel.

Книги Excel для разных людей были созданы из шаблона с использованием VBA, а затем сохранены в нужном месте с правами доступа к папке.

Все рабочие книги были прикреплены к рабочим книгам как внешние таблицы с использованием именованных диапазонов. Затем я мог бы запросить книги из приложения Access. Все административные материалы были сделаны из базы данных, но конечные пользователи имели доступ только к своей рабочей книге.

Разработка приложения Excel / Access таким способом была приятным опытом, а пользовательский интерфейс был более удобным для пользователя, чем при использовании Access.

Я должен сказать, что в этом случае это заняло бы гораздо больше времени в Access, чем в Excel. Кроме того, объектная модель приложения выглядит лучше в Excel, чем в Access.

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

Вы также должны отключить авторасчет при импорте данных.

2 голосов
/ 02 июня 2010

Довольно просто и эффективно использовать Excel в качестве инструмента отчетности для доступа к данным. Быстрый подход «без программирования» заключается в создании списка или сводной таблицы, связанной с вашим внешним источником данных. Но это выходит за рамки Stackoverflow.
Программный подход может быть очень простым:

strProv = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & SourceFile & ";"
Set cnn = New ADODB.Connection  
cnn.Open strProv
Set rst = New ADODB.Recordset
rst.Open strSql, cnn
myDestRange.CopyFromRecordset rst

Вот и все!

1 голос
/ 21 декабря 2011

Я сделал это в одном проекте. Я использовал MDB для хранения данных о счетах и ​​использовал Excel для их рендеринга, предоставляя пользователю возможность их адаптировать.

В этом случае лучшее решение:

  1. Не использовать ADO / DAO в Excel . Я реализовал все как публичные функции в модулях MDB и вызывал их прямо из Excel. Вы можете возвращать даже сложные объекты данных, такие как массивы строк и т. Д., Вызывая функции MDB с необходимыми аргументами. Это похоже на архитектуру клиент-сервер современных веб-приложений: ваше веб-приложение выполняет рендеринг и взаимодействие с пользователем, база данных и средний уровень находятся на стороне сервера.

  2. Использование форм Excel для взаимодействия с пользователем и для визуализации данных.

  3. У меня обычно есть последний лист с некоторыми именами регионов для настроек: путь к файлам MDB, некоторые настройки (текущий пользователь, пароль при необходимости и т. Д.) - так что вы можете легко адаптировать свою реализацию Excel к различным местонахождение ваших "back-end" данных.

1 голос
/ 10 марта 2009

Учитывая простоту использования Access, я не вижу убедительной причины использовать Excel вообще, кроме как для экспорта данных для сокращения чисел. Access предназначен для простого создания форм данных и, на мой взгляд, будет на порядок проще и займет меньше времени, чем при использовании Excel. Несколько часов на изучение объектной модели Access окупят себя много раз с точки зрения времени и усилий.

0 голосов
/ 10 февраля 2010

Вы можете попробовать что-то вроде XLLoop . Это позволяет реализовывать функции Excel (UDF) на внешнем сервере (предусмотрены реализации сервера на многих языках).

Например, вы можете использовать базу данных MySQL и веб-сервер Apache, а затем написать функции на PHP для предоставления данных вашим пользователям.

Кстати, я работаю над проектом, поэтому дайте мне знать, если у вас есть какие-либо вопросы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...