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

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

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

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

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

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

8.08.2008 12:30:48
7 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

15
12.08.2008 20:02:41

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

2
8.08.2008 12:35:16

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

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

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

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

0
11.08.2008 16:01:53

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

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

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

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

1
12.08.2008 18:07:00

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

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

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

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

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

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

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

3
23.06.2009 22:05:11

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

2
15.05.2009 04:34:23

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

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

16
12.09.2009 14:04:24