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

Question

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

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

До сих пор, я столкнулся следующее:

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

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

Answer 1

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

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

Один из возможных альтернатив - разместить бэкэнд (с данными) на общем диске. Я помню, что это хорошо документировано, также в помощи. Вы можете посмотреть на some general advice on splitting into a frontend and a backend и code that automatically reconnects to the backend on startup; Я также могу отправить вам еще один пример кода или отправить его здесь.

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

Answer 5

Gareth Simpson высказал мнение:

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

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

Gareth Симпсон продолжил:

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

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

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

Answer 6

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

Answer 7

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

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

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

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

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

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

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