Проблемы с помощью Доступа MS в качестве фронтенда к бэкенду базы данных MySQL?

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

Gareth Simpson полагается:

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

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

продолженный Gareth Simpson:

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

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

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

В целом это зависит :)

у меня не было большого количества проблем, когда сторона приложения просто обновляла данные через формы. Можно получить предупреждения/ошибки, когда та же строка была обновлена больше чем одним пользователем; но Доступ, кажется, постоянно обновляет свои живые официальные наборы документов все время.

проблемы могут произойти, если Alice уже работает с рекордными 365, и Bob обновляет его, и затем Alice пытается обновить его со своими изменениями. Как я вспоминаю, Alice получит загадочное сообщение об ошибке. Для пользователей было бы легче, если Вы захватываете эти ошибки и по крайней мере даете им более дружественное сообщение об ошибке.

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

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

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

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

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

Dont forget to put some type time/date stamp on each record. sometimes ms access will think "another user has changed or deleted the record" and will not allow you to make a change! I found this out the hard way.

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

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