Доступ MS (MDB) параллелизм
Вы не можете использовать переменную пользователя для представления имени столбца таким образом. Одним из вариантов здесь было бы использовать подготовленный оператор в MySQL:
11 ответов
Это старый вопрос, но никто никогда на него не отвечал. Вот вопросы:
- Как происходит одновременное чтение в MDB?
- Как происходит одновременное обновление/удаление в MDB?
- Существует ли концепция блокировок и как я могу использовать их в .NET приложении?
- Хорошая или ужасная идея размещения MDB файла на сетевом ресурсе?
На первые два вопроса можно ответить одним объяснением. Одно из ключевых предостережений здесь: ответы, которые я даю здесь, специфичны для Jet MDB (и их вариантов) и не полностью применимы к новому формату файла, введенному начиная с A2007 года, т.е. к формату ACCDB. Я не полностью изучил последствия удаления Jet ULS из ACE, и некоторые из приведенных ниже комментариев могут предполагать Jet ULS под капотом. Однако во многих случаях можно заменить "LACCDB-файл" на "LDB-файл", и результаты будут одинаковыми.
1-2). Одновременное чтение/обновление/удаление
Движок базы данных Jet часто называют "файловым сервером" в том смысле, что нет демона на стороне сервера, управляющего вводом/выводом данных с файлами данных на сервере. Это означает, что все клиенты, использующие Jet MDB, читают файл напрямую
Это, конечно, рецепт катастрофы, если нет встроенного механизма для обработки одновременного доступа к файлу.
Jet использует файл блокировки записи, где если ваш MDB - "MyFile.MDB", то файл блокировки записи будет находиться в той же самой папке и называться "MyFile.LDB". LDB файл записывает, что пользователи Jet ULS имеют открытый MDB файл, с какой рабочей станции этот пользователь подключен, и всю информацию, необходимую для согласования вопросов параллелизма.
Для тех, кто режет зубы на движках клиентских/серверных баз данных, это может показаться примитивным и опасным, но в то время, когда разрабатывался движок базы данных Jet, его целью было использование в качестве настольного движка базы данных для небольших рабочих групп, и он конкурировал с другими настольными db движками, такими как xBase и Paradox, оба из которых использовали аналогичные блокирующие файлы для управления одновременным использованием файлов данных от нескольких клиентов.
В файле базы данных Jet блокировки применяются либо на страницах данных (которые в Jet 4 были увеличены до 4K, тогда как в Jet 3.x и ранее они были 2K), либо на уровне записи, если таблица данных была изначально создана для использования блокировки на уровне записи. В первые дни существования Jet 4 блокировка на уровне записи многими была признана довольно медленной, особенно при использовании пессимистической блокировки, поэтому многие разработчики Access никогда не использовали ничего, кроме блокировки на уровне страниц (@David Fenton поднимает руку!)
На самом деле, используя оптимистическую блокировку, вы избегаете большинства параллельных проблем, которые могли бы возникнуть при использовании пессимистической блокировки.
Некоторые предостережения:
из DAO, блокировка на уровне записи недоступна, и вы получаете только блокировку на уровне страницы.
из DAO, существует ряд опций для управления оптимистической/пессимистической блокировкой, в частности, аргумент LockEdits метода OpenRecordset, но он также взаимодействует с некоторыми настройками, указанными в аргументе OpenRecordset Options (например, Опция dbReadOnly не может быть использована с LockEdits). Помимо блокировки, существуют также опции для последовательных/несоответствующих обновлений, и все это может взаимодействовать с транзакциями (например, изменения внутри нефиксированной транзакции не будут видны другим пользователям и, таким образом, не будут конфликтовать с ними, но она может ставить блокировки только для чтения на соответствующие таблицы)
Из ADO/OLEDB эти структуры управления параллельными связями Jet будут отображены на соответствующие функции и аргументы, найденные в ADO/OLEDB. Так как я использую Jet только из Access, я взаимодействую с ним только через DAO, поэтому я не могу посоветовать, как вы управляете ими с помощью ADO/OLEDB, но суть в том, что механизм базы данных Jet предлагает управление блокировкой ваших записей при доступе к ним программно (в отличие от доступа через интерфейс Access UI) - это просто более сложно.
3) Блокировки и .NET
Я не могу дать здесь никаких советов, кроме того, что вы, скорее всего, будете использовать OLEDB в качестве интерфейса данных, но суть в том, что функциональность/контроль блокировки есть в самом движке db, так что, скорее всего, есть способ контролировать его с помощью OLEDB. Однако это может быть не очень красиво, поскольку мне кажется, что OLEDB разработан на основе клиент-серверной архитектуры, и блокировка Jet на основе файлов может не соответствовать этому элегантному способу.
4) MDB на сетевом разделяемом ресурсе
Jet очень чувствителен к малейшей заминки в любом сетевом подключении. Поэтому сети с низкой пропускной способностью могут увеличить уязвимость баз данных Jet, открытых при медленном соединении.
Это потому, что основные куски файла базы данных должны быть вытянуты по проводу в оперативную память локального компьютера для обработки. Теперь многие люди ошибочно утверждают, что весь файл MDB тянут по проводу, или что целые таблицы тянут по проводу. Это неправда. Вместо этого Jet сначала запрашивает индексы (и запросы не более, чем необходимы для выполнения запроса), а затем из этого результата точно определяет, какие страницы данных нужны, и затем тянет только эти страницы. Это удивительно эффективно и быстро.
Кроме того, Jet выполняет очень умное кэширование, которое может означать, что первый запрос данных может занять некоторое время, но последующие запросы тех же самых данных происходят почти мгновенно из-за кэширования.
Теперь, если вы не проиндексировали свои таблицы хорошо, вы можете в конечном итоге вытянуть всю таблицу и выполнить полное сканирование таблицы. Аналогично, если вы основываете критерии на клиентских функциях, которые не являются частью SQL-диалекта Jet, вы можете в конечном итоге вытащить полную таблицу (сортировка, скажем, Replace(MyField, "A", "Z"), скорее всего, вызовет полное сканирование таблицы). Но такие вещи будут неэффективны и с архитектурой клиент/сервер, так что это просто здравый смысл - разработать схему, чтобы правильно индексировать вещи и быть осторожным с использованием UDF или не Jet-совместимых функций. В общем, те же самые вещи, которые эффективны с клиентом/сервером, будут эффективны и с Jet (главное отличие заключается в том, что с Jet лучше использовать постоянное соединение, чтобы избежать накладных расходов, связанных с воссозданием LDB-файла, что очень важно)
Другое, чего следует избегать, - это попытки использовать данные Jet через WiFi-соединение. Мы все знаем, насколько ненадежен WiFi, и это просто проблема, связанная с попытками работать с Jet-данными через WiFi-соединение.
Итог:
Если вы используете MDB в качестве хранилища данных для обслуживания данных с веб-сервера, вы должны поместить данные как можно ближе к оперативной памяти веб-сервера. Это означает, что там, где это возможно, на дисковый том, который прикреплен к физическому веб-серверу. Там, где это невозможно, необходимо быстрое и надежное LAN соединение. Локальные сети GB в центрах обработки данных довольно распространены в наши дни, и мне было бы очень удобно работать с данными Jet через такое соединение.
Для совместного использования, например, нескольких клиентских рабочих станций, на которых запущено приложение VB.NET desktop, совместно использующее один Jet MDB в качестве хранилища данных, довольно безопасно иметь файл данных на надежном файловом сервере. Где это возможно, хорошей идеей будет размещение ваших Jet MDB файлов на машинах, которые не служат нескольким целям (например, ваш контроллер домена, который работает под управлением Exchange, SQL Server и действует в качестве файлового сервера и сервера печати, может оказаться не самым лучшим местом). Такие приложения, как Exchange, могут сильно мешать работе файлового сервера, и я обычно рекомендую никогда не размещать MDB файлы на сервере, который является многозадачным в качестве сервера Exchange, если только это не очень большой объем.
Другие соображения:
никогда не пытайтесь распространять MDB на реплицированной файловой системе, если только все пользователи не используют одну и ту же реплику. То есть, если у вас есть два сервера, реплицирующие файлы между ними, даже не думайте редактировать файл MDB с обоих серверов. Это практически сразу же испортит файл.
Я бы не рекомендовал хранить любой MDB на чем-либо, кроме родной файловой системы Windows, обслуживаемой через родные сети Microsoft SMB. Это означает отсутствие Novell, Linux, SAMBA. Ключевой причиной этого является то, что в файловой системе Windows есть низкоуровневые крючки из Jet в некоторые низкоуровневые функции блокировки, которые не на 100% реплицируются на другие файловые системы. Теперь я очень консервативен в этом вопросе, и многие компетентные разработчики Access сообщили о отличных результатах с правильно настроенными файловыми серверами Novell (часто требуются некоторые настройки блокировки записи, хотя это может быть менее актуально в наши дни - я даже не знаю, существует ли уже Novell!), а также молниеносная производительность с файловыми серверами на базе Linux под управлением SAMBA. Я осторожно отношусь к этому и рекомендовал бы любого клиента против этого (сюда также входят различные SAN-устройства, так как не многие из них основаны на Windows)
Я бы никогда не запустил их на любой виртуальной файловой системе по тем же самым причинам. Однако у меня есть клиент, который уже несколько лет без проблем запускает свое однопользовательское приложение Access под Parallels на Mac Air. Но это однопользовательское приложение, поэтому проблемы с блокировкой будут относительно незначительными.
Не знаю, ответит ли оно на ваши вопросы или нет. Все это основано на моем 13-летнем регулярном использовании Jet в качестве разработчика Access и изучении единственной опубликованной книги по Jet - Jet Database Engine Programmers Guide (только для Jet 3.5). Я не предоставил никаких реальных ссылок, но если кому-то понадобятся какие-то подробности о чем-то, что я сказал, я проведу исследование, если смогу.
.Я создал приблизительно дюжину приложений малого бизнеса в Доступе за эти годы. Большинство имеет макс. из 10-20 пользователей на них за один раз. Базы данных разделяются между "приложением" и базой данных "данных". Производительность достойна и никакие проблемы с параллелизмом. Также повреждение было в основном несуществующим начиная с Access 2000 SP2.
Существует много людей, говорящих, "никогда не используют Доступ" - хорошо, если он сделан правильно (т.е. профессиональным разработчиком), Доступ является вполне прекрасным пакетом разработки, и я сделал хорошее проживание в нем. Мои клиенты очень довольны тем, что я создал.
Я записал два коммерческих продукта, которые используют базу данных Access, работающую от сетевого ресурса, для обычно до 10 пользователей. Если Вы не злоупотребляете им, нет действительно никакой проблемы; но поскольку Вы видите, что многие разработчики никогда не добираются там - и из-за его характера низкого уровня, существует много дрянных взломов, основывался на нем. В случае одного продукта я должен был перепроектировать приложение из-за всех проблем, описанных подробно другими; но после того, как я очистил его, у меня никогда не было проблемы целостности БД через сотни установок.
Его большим преимуществом является единственная база данных файла, которой легко создать резервную копию, восстанавливает и копирует в Ваш ноутбук для разделения. В значительной степени все альтернативы, включая sqlite (хотя некоторые не допустят его), требуют некоторой формы внимания DBA время от времени.
В большинстве случаев Доступ обеспечивает рекордные блокировки и блокировки файла для некоторого DDL (например, изменения схемы) по умолчанию.
Но Microsoft - в основном obsoleting это, и некоторые Ваши коллеги поместят презрение в "кучу" на Вас для использования его.
(В этой точке я обычно утка для покрытия и вопля "ПОСТУПЛЕНИЕ!!!".)
Доступ является действительно рабочим столом, решением отдельного пользователя. На практике это имеет верхний пользовательский предел "одного".
Это - также локальный механизм. Таким образом, при выполнении запроса данные вытягивают по сети к локальному Реактивному двигателю для обработки. .ldb файл помещается в сетевой ресурс для управления блокировками.
При использовании серверного механизма (MSSQL, MySQL, Sybase, 'Orable и т.д.) затем, Вы отправляете запрос механизму, который обрабатывает его и возвращает результаты Вам. Блокировки сохранены внутренне.
Это имеет огромные последствия для производительности, устойчивости и целостности данных.
Если Ваш пользователь решает нажать кнопку сброса, Доступ databse имеет справедливый шанс того, чтобы быть поврежденным, и необходимо будет удалить .ldb.
С надлежащим механизмом базы данных (MSSQL, Sybase, 'Orable: Мне не нравятся резервные копии MySQL), затем Вы также надлежащая резервная возможность. Если у Вас нет некоторого whizzy программного обеспечения для резервного копирования inuse файлов, возможно, что у Вас не будет резервных копий Вас данными в Доступе DB.
Я упомянул блокировки конкретно, потому что механизм дб может обработать параллелизм и транзакцию намного более эффективно и изящно, чем какая-либо основанная на файле система.
Я вижу использование проекта Access как фронтэнд для механизма базы данных, но не инвестирование в полное клиентское приложение с бэкендом Доступа.
Я использовал Доступ, или более правильно, Струя как бэкенд на очень небольшом, частном сайте, который никогда не может расти, поскольку это ограничено размером профессии в этой небольшой стране. За три года у меня не было проблем. Существует меньше чем 100 пользователей приблизительно с тридцатью - сорока использованиями его каждый день. Таблицы имеют несколько тысяч записей.
У меня нет большого опыта с Доступом, но эта ссылка может быть полезна для Вас:
http://office.microsoft.com/en-us/access/HP052408601033.aspx
"Можно поместить всю базу данных Access на сетевой сервер или в совместно используемой папке. Это - самый легкий метод для реализации. Все совместно используют данные и используют те же формы, отчеты, запросы, макросы и модули. Используйте эту стратегию, если Вы хотите, чтобы все использовали базу данных Access тот же путь или если Вы не можете поддерживать пользователей, создающих их собственные объекты".
"При открытии файла базы данных Access (.mdb) в общем режиме Microsoft Access также создает файл информации о блокировке (.ldb) с тем же именем файла (например, Northwind.ldb) и в той же папке как файл базы данных. Эта информация о блокировке хранилища файлов имя компьютера (такие как mypc) и имя безопасности (такие как Администратор) каждого общего пользователя базы данных. Microsoft Access использует эту информацию для управления параллелизмом. В большинстве случаев Microsoft Access автоматически удаляет файл информации о блокировке, когда последний пользователь закрывает файл базы данных".
Доступ, как предполагается, является многопользовательским - я думаю, что Microsoft рекомендует это максимум для 4 или 5 пользователей, но на практике я рекомендовал бы никогда не использовать базу данных Access, где существуют больше, чем отдельный пользователь, хотя, если у Вас действительно нет выбора, это приемлемо для два или три, учитывая определенный provisos.
У меня был опыт четырех или пяти систем с помощью бэкенда базы данных Access - всех полученных от других 'разработчиков' - и во всех случаях я переместил их в SQL Server как как приоритет после любых незамедлительных обновлений, и фиксирует требуемый при взятии контракта - обычно, как только я мог говорить босс, оплачивающий счет в него. Отрезок времени для этого обычно является несколькими месяцами, таким образом, я видел, что он работает параллельный в течение разумного отрезка времени в соответствии с несколькими различными приложениями.
На самом деле это будет обычно работать проходимо хорошо, если система не будет иметь большого количества параллельных, вставляет/обновляет и в большой степени не используется. Главные практические проблемы, по моему опыту..
Это склонно к повреждению - это просто делает. Обычно это не слишком много проблемы как открытие файла и рабочий компактный, и восстановление разберется в проблемах, но хороший резервный режим абсолютно необходим.
Это медленно. Каждый раз, когда я обновил систему до SQL Server, я получил много престижности за ускорение системы от пользователей.
Файл базы данных чрезмерно увеличивается в размерах из-за способа, которым Доступ отмечает записи, как обновлено или удалено. Это далее замедляет систему, поскольку файл должен быть загружен по сети. Следовательно, некоторый режим, который сжимает данные, обычно ежедневно, важен.
Все вышеупомянутое является намного меньше проблемы с системами отдельного пользователя как базовые проблемы, которые запрашивают, они являются намного менее видными.
В целом, я должен подчеркнуть, что никогда не рекомендовал бы Доступа ни для какой многопользовательской системы. Однако, если действительно будут иметь также, то Вы, вероятно, выйдете сухим из воды, пока это - слегка используемое приложение, и Вы действительно устанавливаете процедуры резервного копирования и процедуры технического обслуживания.
При движении с сетевым ресурсом я пошел бы с включенной базой данных сети (mysql/firebird/mssql) вместо доступа.
Для ситуации Ваше описание Доступа использования не было бы проблемой.
Я использовал Доступ в более сложных ситуациях затем это главным образом при работе с веб-сайтами, когда Доступом не злоупотребляют чрезмерно, действительно не случается так что плохо механизма базы данных. (не говорящий о формах и материале как этот просто таблицы и записи)
Когда Ваше выполнение вставляет/обновляет/удаляет от нескольких пользователей сразу затем, это становится немного волосатым. Это - точка, где Вы начинаете думать о реальных механизмах базы данных.
Также, когда Вы хотите низкую служебную базу данных, которая ориентирована на многопотоковое исполнение, можно взглянуть на vistadb (медленнее затем доступ, не всегда свободный, 100%.NET)
Я думаю, что блокировки уровня таблицы использования доступа с некоторыми вещами механизма организации очередей должны работать хорошо. Если Ваше взволнованное об этом можно всегда бросать моделируемый стресс-тест в него.
Это было уже указано несколько раз для использования реальной многопользовательской, свободной платформы базы данных. Но одна из причин, почему не был указан. Эта причина, сколько существующих, грязных, неприятных, больших баз данных Access началось как "несколько записей, один или два пользователя макс."? Я рисковал бы сказать всех их.
Если нет только два или три сотрудника в целой компании, разногласия - то, что при разработке полезной части программного обеспечения она собирается в конечном счете использоваться больше, чем исходные два или три пользователя, иметь больше, чем исходное небольшое количество тысячи записей, и расширится за эти годы для включения многих форм, значительно большего количества таблиц и намного большего количества данных. Вы не можете восстановить основу дома, после того как дом создается. Создайте прочную основу сегодня, и можно развернуть дом до содержания основы. То же для программного обеспечения.
Я думаю, что можно определить его в строке соединения приложения .NET. Я погуглил для СТРУИ, доступа и захвата записей
вот ссылка, которая могла бы помочь.
См. принятый ответ для реальных деталей о том, как Доступ и СТРУЯ получают данные.
Не используйте Доступ для многопользовательского сценария.
Я только что прошел две недели боли, потому что мой предшественник на проекте выбрал Access в качестве бэкэнда.
Конкретные причины:
- Нет такой вещи как Linq к доступу
- Доступ имеет многочисленные причуды как зависимости от порядка добавления параметров к командам, которые возьмут Вас возрасты для отладки
- Доступ не масштабируется
- Обновления базы данных являются тяжелой работой по сравнению с использованием SQL Server