Проблемы с использованием MS Access в качестве интерфейса к серверной части базы данных MySQL?

Два пользователя хотели использовать одну и ту же базу данных, изначально написанную в MS Access, без конфликтов друг с другом из-за одного файла MDB.

Я переместил таблицы из простой базы данных MS Access в MySQL, используя его Migration Toolkit (который, кстати, работает хорошо), и настроил Access для связи с этими таблицами через ODBC.

Пока что я столкнулся со следующим:

  • Вы не можете вставлять / обновлять / удалять строки в таблице без первичного ключа (неудивительно).
  • Поля AutoNumber в MS Access должны быть первичным ключом, иначе они будут просто целочисленными столбцами в MySQL (natch, почему бы не быть PK?)
  • Таблицы были перенесены в тип MySQL InnoDB, но отношения доступа не стали ограничениями внешнего ключа MySQL.

Могу ли я ожидать каких-либо других проблем после использования базы данных? В частности, когда оба пользователя работают в одной таблице?

Ответов (7)

Решение

У меня было приложение, которое работало аналогичным образом: интерфейс MS Access для серверной части MySQL. Это было настолько больно, что вместо этого я написал интерфейс Win32. Наверху я столкнулся со следующими проблемами:

  • Похоже, что разработка связи ODBC давно прекратилась. Вокруг ходят разные версии - очень запутанные. Ссылка ODBC не поддерживает Unicode / UTF8, и я помню, что с ней были и другие проблемы (хотя некоторые из них можно было преодолеть путем тщательной настройки).
  • Вероятно, вы захотите вручную настроить схему базы данных, чтобы сделать ее совместимой с MS Access. Я вижу, вы уже узнали о необходимых суррогатных ключах (т.е. первичных ключах типа int) :-)
  • Вы должны иметь в виду, что вам может потребоваться использовать сквозные запросы для выполнения более сложных SQL-манипуляций с базой данных MySQL.
  • Будьте осторожны с использованием большого количества VBA, так как это может повредить ваш файл внешнего интерфейса. Требуется регулярное сжатие базы данных (с помощью главного меню Инструменты | Утилиты базы данных | Сжатие и восстановление или что-то в этом роде - я использую голландскую версию) и создание большого количества резервных копий.
  • Доступ имеет тенденцию вызывать большой сетевой трафик. Типа, действительно огромные партии. Я не смог найти для этого решения. Если вы хотите следить за этим, рекомендуется использовать сетевой монитор!
  • Access настаивает на хранении логических значений как 0 / -1. IMHO, 0 / + 1 имеет больше смысла, и я считаю, что это также способ делать что-то в MySQL по умолчанию. Это не большая проблема, но если ваши флажки не работают, вы обязательно должны это проверить.

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

В противном случае вы также можете рассмотреть MS SQL. У меня нет опыта в этом, но я полагаю, что он работает вместе с MS Access намного лучше!

Не забудьте поставить отметку времени / даты на каждой записи. иногда MS Access будет думать, что «другой пользователь изменил или удалил запись», и не позволит вам внести изменения! Я выяснил это на собственном горьком опыте.

Я знаю, что это не дает прямого ответа на ваш вопрос, но, возможно, стоит попробовать средство миграции SQL Server 2005 для Access . Я никогда не использовал этот инструмент, но, возможно, стоит использовать его с SQL Server 2005 Express Edition, чтобы увидеть, есть ли те же проблемы, что и у вас с MySQL.

Если это всего два пользователя, тогда Access будет работать нормально, если вы поместите .mdb на общий диск.

Вы попробовали это сначала, а не просто предположили, что это будет проблемой.

Я считаю, что рекомендуемое максимальное количество одновременных пользователей для Access - 5, но иногда я пропускал это и никогда не откладывал.

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

В общем, смотря как :)

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

Проблемы могут возникнуть, если Алиса уже работает с записью 365, и Боб обновляет ее, а затем Алиса пытается обновить ее своими изменениями. Насколько я помню, Алиса получит загадочное сообщение об ошибке. Пользователям будет легче, если вы перехватите эти ошибки и, по крайней мере, предоставите им более понятное сообщение об ошибке.

У меня было больше проблем, когда я редактировал записи в коде VB через RecordSets, особенно в сочетании с редактированием тех же данных в формах. Это не обязательно многопользовательская проблема; однако у вас почти такая же ситуация, потому что у вас есть один пользователь с несколькими подключениями к одним и тем же данным.

Гарет Симпсон высказал мнение:

Если это всего два пользователя, тогда Access будет работать нормально, если вы поместите .mdb на общий диск.

Э, нет. Не существует многопользовательского приложения Access, для которого у каждого пользователя не должно быть выделенной копии внешнего интерфейса. Это означает, что у каждого пользователя должен быть MDB на своей рабочей станции. Почему? Потому что объекты во внешних интерфейсах плохо совместно используются (не так хорошо, как таблицы данных Jet, хотя в этом сценарии их нет, использующих MySQL в качестве серверной части).

Гарет Симпсон продолжил:

Я считаю, что рекомендуемое максимальное количество одновременных пользователей для Access - 5, но иногда я пропускал это и никогда не откладывал.

Нет, это совершенно неверно. Теоретический предел для пользователей MDB составляет 255. Это, конечно, нереально, поскольку как только вы наберете около 20 пользователей, вам придется тщательно запрограммировать приложение Access, чтобы оно хорошо работало (хотя то, что вам нужно делать в Access-to- Приложение Jet - это то же самое, что вы сделали бы, чтобы сделать любое приложение серверной базы данных эффективным, например, извлечение наименьших используемых наборов данных).

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

Я знаю, что эта тема не слишком свежая, но просто некоторые дополнительные пояснения:

Если вы хотите эффективно использовать MS Access, особенно с большими многопользовательскими базами данных, сделайте следующее:

  • разделите свой MDB на файлы внешнего приложения и серверные (только данные) файлы - тогда у вас будет два отдельных файла MDB.

  • перенести все таблицы с данными и структурой во внешнюю базу данных. Это может быть: MySQL (работает очень хорошо, без ограничений по размеру базы данных, требует дополнительных навыков, поскольку это не технология MS, но во многих случаях это хороший выбор - кроме того, вы можете масштабировать свой бэкэнд с большим объемом оперативной памяти и дополнительными процессорами, так что все зависит от ваших потребностей и возможностей оборудования); Oracle (если у вас достаточно денег или какая-то корпоративная лицензия) или Oracle 10g XE (если это не проблема, размер базы данных ограничен до 4 ГБ, и он всегда будет использовать 1 ГБ ОЗУ и 1 ЦП), MS SQL Server 2008 (это отличная пара, чтобы иметь внешний интерфейс MS Access и серверную часть MS SQL Server во всех случаях, но вы должны платить за лицензию! - преимущества: тесная интеграция, обе технологии от одного поставщика;

  • повторно свяжите ваш интерфейс 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, и я очень доволен (как разработчик, поддерживающий это приложение). Друзья мои, пользователи также довольны, поскольку они чувствуют себя очень комфортно с графическим интерфейсом (интерфейс), скоростью (MySQL), у них нет проблем с блокировкой записей или производительностью базы данных.

Более того, важно много читать о передовых методах работы и опыте других людей. Я бы сказал, что во многих случаях MS Access - хорошее решение. Я знаю много специализированных, изготовленных на заказ систем, которые начинались как эксперимент в форме частной базы данных MS Access (файл MDB), а затем превратились в: разделенный MS Access (MDE - интерфейс, MDB - бэкэнд) и, наконец, интерфейс MS Access. (MDE) и «серьезный» сервер базы данных (в основном MS SQL Server и MySQL). Также важно, чтобы вы всегда могли использовать свое решение MS Access в качестве рабочего прототипа - у вас есть готовый бэкэнд в своей базе данных (предположим, MySQL), и вы можете переписать интерфейс в соответствии с технологией по вашему выбору (веб-решение? Может быть, настольный C# приложение - то, что вам нужно!).

Надеюсь, я помог некоторым из вас при рассмотрении работы с MS Access.

С уважением, Вавжин http://dcserwis.pl