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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

Answer 5

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

Answer 6

В общем, это зависит:)

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

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

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

Answer 7

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

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

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

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