Проблемы с использованием MS Access в качестве интерфейса для серверной части базы данных MySQL?
https://stackoverflow.com/questions/5842
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Два пользователя хотели совместно использовать одну и ту же базу данных, изначально написанную в MS Access, не конфликтуя друг с другом из-за одного MDB-файла.
Я перенес таблицы из простой базы данных MS Access в MySQL, используя ее Инструментарий для миграции (что, кстати, хорошо работает) и настройте доступ к ссылке на эти таблицы через ODBC.
До сих пор я сталкивался со следующим:
- Вы не можете вставлять / обновлять / удалять строки в таблице без первичного ключа (в этом нет ничего удивительного).
- Поля автоматической нумерации в MS Access должны быть первичным ключом, иначе они просто закончатся как целочисленные столбцы в MySQL (естественно, почему бы этому не быть PK?)
- Таблицы были перенесены в табличный тип MySQL InnoDB, но отношения доступа не стали ограничениями внешнего ключа MySQL.
Как только база данных будет запущена, могу ли я ожидать каких-либо других проблем?Особенно, когда оба пользователя работают в одной таблице?
Решение
У меня было приложение, которое работало аналогично:интерфейс MS Access для серверной части MySQL.Это была такая огромная боль, что в итоге я написал интерфейс Win32 вместо этого.С самого начала я столкнулся со следующими проблемами:
- Разработка ODBC-ссылки, похоже, давно прекратилась.Существуют различные версии, плавающие вокруг --- очень запутанные.Ссылка ODBC не поддерживает Unicode / UTF8, и я помню, что с ней были и другие проблемы (хотя некоторые из них можно было преодолеть путем тщательной настройки).
- Вероятно, вы захотите вручную настроить схему своей базы данных, чтобы сделать ее совместимой с MS Access.Я вижу, вы уже узнали о необходимых суррогатных ключах (т.е. первичных ключах int) :-)
- Вы должны иметь в виду, что вам может потребоваться использовать сквозные запросы для выполнения более сложных SQL-манипуляций с базой данных MySQL.
- Будьте осторожны с использованием большого количества VBA, так как это может привести к повреждению вашего файла интерфейса.Регулярно сжимаю базу данных (используя главное меню, Сервис | утилиты базы данных | Сжатие и восстановление или что-то в этом роде - я использую голландскую версию) и создаю Лоты необходимо создавать резервные копии.
- Доступ, как правило, приводит к большому объему сетевого трафика.Например, действительно огромные партии.Я не смог найти решение для этого.Рекомендуется использовать сетевой монитор, если вы хотите следить за этим!
- Access настаивает на сохранении логических значений как 0 / -1.ИМХО, 0 / + 1 имеет больше смысла, и я считаю, что это стандартный способ выполнения задач и в MySQL.Не такая уж большая проблема, но если ваши флажки не работают, вам обязательно следует это проверить.
Одной из возможных альтернатив было бы поместить серверную часть (вместе с данными) на общий диск.Я помню, что это хорошо задокументировано, в том числе в справке.Возможно, вы захотите взглянуть на несколько общих советов по разделению на внешний интерфейс и серверную часть и код, который автоматически повторно подключается к серверной части при запуске;Я также могу выслать вам еще несколько примеров кода или разместить его здесь.
В противном случае вы также можете рассмотреть MS SQL.У меня нет опыта в этом, но я предполагаю, что это работает вместе с MS Access гораздо приятнее!
Другие советы
Я знаю, что эта тема не слишком свежая, но просто несколько дополнительных пояснений:
Если вы хотите эффективно использовать MS Access, особенно с большими многопользовательскими базами данных, пожалуйста, выполните следующие действия:
разделите свой MDB-файл на файлы внешнего интерфейса приложения и серверной части (только для данных) - тогда у вас будут два отдельных MDB-файла.
перенесите все таблицы с данными и структурой во внешнюю базу данных.Это может быть:MySQL (работает очень хорошо, ограничений по размеру базы данных нет, требует дополнительных навыков, поскольку это не технология MS, но во многих случаях это хороший выбор - более того, вы можете масштабировать свой сервер с большим объемом оперативной памяти и дополнительными процессорами, так что все зависит от ваших потребностей и аппаратных возможностей);Oracle (если у вас достаточно денег или какая-то корпоративная лицензия) или Oracle 10g XE (если это не проблема, поскольку размер базы данных ограничен 4 ГБ и она всегда будет использовать 1 ГБ оперативной памяти и 1 процессор), MS SQL Server 2008 (это отличная пара для использования интерфейса MS Access и серверной части MS SQL Server во всех случаях, но вам придется заплатить за лицензию!- преимущества заключаются в следующем:тесная интеграция, обе технологии от одного и того же поставщика;MS SQL Server очень прост в обслуживании и эффективен в то же время) или Express edition (та же история, что и с Oracle XE - почти те же ограничения).
повторно свяжите ваш интерфейс MS Access с внутренней базой данных.Если вы выбрали MS SQL Server в качестве серверной части, то это будет так же просто, как воспользоваться мастером из MS Access.Для MySQL - вы должны использовать драйверы ODBC (это просто и работает очень хорошо).Для Oracle - пожалуйста, не используйте драйверы ODBC от Microsoft.Они от Oracle будут выполнять свою работу намного лучше (вы можете сравнить время, необходимое для выполнения SQL-запроса из MS Access в Oracle через драйверы Oracle ODBC и MS Oracle ODBC).На этом этапе у вас будет надежный сервер базы данных и полностью функциональный интерфейс MS Access - MDB-файл.
скомпилируйте свой интерфейс MDB в MDE - это даст вам большую скорость.Более того, это единственная разумная форма распространения приложения MS Access среди ваших конечных пользователей.
для повседневной работы - используйте файл MDE с интерфейсом MS Access.Для дальнейшей разработки интерфейса MS Access используйте MDB-файл.
не используйте плохо написанные компоненты ActiveX для расширения возможностей интерфейса MS Access.Лучше напишите их сами или купите подходящие.
не верьте мифам о том, что с MS Access много проблем - это отличный продукт, который может помочь в некоторых случаях.Проблема в том, что многие люди предполагают, что это игрушка или что MS Access в целом проста.Обычно они сами по себе порождают множество ошибок и проблем из-за недостатка знаний и опыта.Для успешной работы с MS Access важно понимать этот инструмент - это то же правило, что и для любой другой существующей технологии.
Я могу сказать вам, что я использую довольно продвинутый MS Access, подключенный к серверной части MySQL, и я очень доволен (как разработчик, который поддерживает это приложение).Друзья мои, пользователи также довольны, поскольку они чувствуют себя очень комфортно с графическим интерфейсом (frontend), скоростью (MySQL), у них нет никаких проблем с блокировкой записей или производительностью базы данных.
Более того, важно много читать о передовой практике и опыте других людей.Я бы сказал, что во многих случаях MS Access является хорошим решением.Я знаю много специализированных, созданных на заказ систем, которые начинались как эксперимент в виде частной базы данных MS Access (MDB-файл), а затем эволюционировали до:разделенный MS Access (MDE - интерфейс, MDB - серверная часть) и, наконец,:Интерфейс MS Access (MDE) и "серьезный" сервер базы данных (в основном MS SQL Server и MySQL).Также важно, что вы всегда можете использовать свое решение MS Access в качестве рабочего прототипа - у вас есть готовый к использованию бэкэнд в вашей базе данных (предположим, MySQL), и вы можете переписать интерфейс под выбранную вами технологию (веб-решение?может быть, настольное приложение на C # - то, что вам нужно!).
Я надеюсь, что помог некоторым из вас при рассмотрении работы с MS Access.
С уважением, Wawrzyn http://dcserwis.pl
Гарет Симпсон высказал мнение:
Если это только два пользователя, то Access должен работать просто отлично, если вы поместите файл .mdb на общий диск.
Э-э, нет.Не существует приложения с многопользовательским доступом, для которого у каждого пользователя не должно быть выделенной копии интерфейса.Это означает, что каждый пользователь должен иметь MDB на своей рабочей станции.Почему?Потому что объекты во внешних интерфейсах не очень хорошо совместно используются (далеко не так хорошо, как таблицы данных Jet, хотя ни один из них в этом сценарии не использует MySQL в качестве серверной части).
Гарет Симпсон продолжил:
Я считаю, что рекомендуемое максимальное количество одновременных пользователей для доступа равно 5, но иногда я преодолевал это и никогда не отклеивался.
Нет, это совершенно неверно.Теоретический лимит для пользователей MDB равен 255.Конечно, это нереально, поскольку, как только вы охватите около 20 пользователей, вам придется тщательно запрограммировать свое приложение Access, чтобы оно работало хорошо (хотя то, что вам нужно делать в приложении Access-to-Jet, - это то же самое, что вы бы сделали для повышения эффективности любого серверного приложения базы данных, например, для извлечения наименьших доступных наборов данных).
В этом случае, поскольку у каждого пользователя должна быть индивидуальная копия интерфейсного MDB, многопользовательские ограничения Access / Jet просто вообще не имеют значения.
Я знаю, что это не дает прямого ответа на ваш вопрос, но, возможно, стоит ознакомиться с Средство миграции SQL Server 2005 для доступа.Я никогда не пользовался этим инструментом, но, возможно, его стоит использовать с SQL Server 2005 Express Edition, чтобы посмотреть, есть ли те же проблемы, что и у вас с MySQL
Не забудьте поставить какой-либо тип метки времени / даты на каждой записи.иногда ms access подумает, что "другой пользователь изменил или удалил запись", и не позволит вам внести изменения!Я узнал об этом на собственном горьком опыте.
В общем, это зависит:)
У меня не было особых проблем, когда сторона приложения просто обновляла данные через формы.Вы можете получать предупреждения / ошибки, когда одна и та же строка была обновлена более чем одним пользователем;но Access, похоже, постоянно обновляет свои наборы живых записей.
Проблемы могут возникнуть, если Алиса уже работает с записью 365, и Bob обновляет ее, а затем Алиса пытается обновить ее своими изменениями.Насколько я помню, Алиса получит загадочное сообщение об ошибке.Пользователям было бы проще, если бы вы отслеживали эти ошибки и, по крайней мере, выдавали им более дружелюбное сообщение об ошибке.
У меня было больше проблем, когда я редактировал записи в коде VB с помощью наборов записей, особенно в сочетании с редактированием тех же данных в формах.Это не обязательно многопользовательская проблема;однако у вас почти такая же ситуация, потому что у вас есть один пользователь с несколькими подключениями к одним и тем же данным.
Если это только два пользователя, то Access должен работать просто отлично, если вы разместите файл .mdb на общем диске.
Попробовали ли вы это сначала, а не просто предполагали, что это будет проблемой?
Я считаю, что рекомендуемое максимальное количество одновременных пользователей для доступа равно 5, но иногда я пропускал это мимо ушей и никогда не отклеивался.
С другой стороны, я когда-то использовал Access в качестве интерфейса к MySQL в однопользовательской среде (me).Это был на редкость неприятный опыт, я не могу представить, что с двумя пользователями он стал бы приятнее.
