РИС. 6.5. Исходный вид формы frmCustomersOrders после вставки данных в объект DataSet
2. Щелкните на пиктограмме с изображением знака "плюс", раскроется список ссылок на две таблицы объекта DataSet.
3. Щелкните на ссылке Customers, и в сетке будут отображены данные из таблицы tblCustomers. Обратите внимание, что каждая строка в таблице tblCustomers имеет кнопки с изображением знака "плюс" с левой стороны, что означает связь этой таблицы с другими таблицами. После щелчка на такой кнопке раскрывается список объектов DataRelations для данной таблицы. В нашем примере имеется только одна ссылка для отношения Customer_Orders, созданного в подпрограмме btnFillClick (рис. 6.6).
РИС. 6.6. Ссылка Customer_Orders для первой записи из таблицы Customers
4. Щелкните на ссылке Customer_Orders в первой записи. На основании определения отношения Customer_Orders будут вставлены и отображены записи из таблицы Orders, которые относятся к текущей записи из таблицы Customers.
НА ЗАМЕТКУ
При переходах между разными таблицами и отношениями можно всегда вернуться исходному положению в используя кнопку Navigates back to the parent rows (Обратный переход к родительским записям) с изображением стрелки в правом верхнем углу формы.
Теперь с помощью этой формы пользователи могут просматривать имеющиеся и вводить новые данные. При вводе новой дочерней записи значение 1 в поле указывается автоматически, потому что сетка способна определить его в связанной записи из родительской таблицы. Продолжим и добавим значения для полей OrderDate и Amount. При этом не нужно задавать значение для поля ID, потому что это идентификационное поле, которому значение присваивается автоматически.
5. Щелкните на кнопке Update для выполнения подпрограммы btnUpdate_Click из листинга 6.7, которая вносит указанные изменения данных в базу данных.
6. Чтобы проверить корректность внесенных изменений, щелкните на кнопке Fill для повторной загрузки информации из базы данных в объект DataSet и сетку. Откройте первую запись таблицы Customers и найдите ее дочерние записи. Убедитесь в том, что среди них находится введенная вами дочерняя запись.
Попробуйте внести дополнительные изменения в базу данных вставляя, удаляя и изменяя записи в обеих таблицах и проверяя выполнение обновлений.
НА ЗАМЕТКУ
Успешное удаление записи из родительской таблицы Customer вместе с ее дочерними записями из таблицы Orders возможно благодаря заданному по умолчанию ограничению ForeignKeyConstraint для отношения Customer_Orders, которое заключается в каскадном обновлении (удалении) данных в родительской и дочерней таблицах.
Резюме
В этой главе рассмотрен объект DataAdapter, который является одним из основных объектов модели ADO.NET. Он играет роль моста между неподключенными объектами DataSet (и связанными с ними объектами) и подключенными объектами DataProvider, которые фактически связаны и подключены к физическому источнику данных.
Объект DataAdapter используется для вставки данных в объект DataSet из источника данных с помощью явно заданных команд или хранимых процедур. Объект DataAdapter также автоматически обновляет источник данных теми изменениями, которые произошли в объекте DataSet, что позволяет полностью настроить команды вставки, обновления и удаления для источника данных.
Вопросы и ответы
Иногда требуется программно создать и вставить в набор несколько записей, а затем внести эти обновления в базу данных. В модели ADO 2.X можно создать набор записей, но нельзя обновить базу данных. А как обстоит дело в модели ADO.NET?
В модели ADO.NET это требование реализуется очень просто. Как отмечалось в главе 5, "ADO.NET: объект DataSet", объект DataSet является контейнером данных, который не зависит от фактически используемого источника данных. Для обновления базы данных изменениями из объекта DataSet достаточно только подключиться к уже сконфигурированному объекту DataAdapter и вызвать его метод Update, который фактически обновит базу данных. Это верно и для программно созданных объектов DataSet, а не только для созданных с помощью команды Select объектов DataAdapter. В момент готовности к внесению изменений в физический источник данных достаточно подключиться к сконфигурированному объекту DataAdapter и вызвать его метод Update.
ГЛАВА 7
ADO.NET: дополнительные компоненты
В предыдущих главах рассматривается архитектура модели доступа к данным ADO.NET, объекты модели ADO.NET, их основные свойства и методы. В данной главе описываются четыре дополнительных компонента модели ADO.NET, которые имеют огромное значение для создания профессиональных приложений.
Обнаружение конфликтов при параллельном доступе к данным
Разработчики, имеющие опыт создания многопользовательских баз данных, знают о потенциальных проблемах при параллельном доступе к данным, возникающих при попытке одновременного обновления одних и тех же данных со стороны нескольких пользователей. Допустим, что пользователь А считывает какие-то данные и пользователь Б считывает те же данные, затем пользователь А изменяет эти данные, а пользователь Б также пытается их изменить. Как можно решить эту проблему? Существует два основных способа решения конфликтных ситуаций при параллельном доступе к данным.
Первый способ — пессимистическая блокировка (или пессимистическое управление параллельностью) — решает проблему перезаписи пользователем Б изменений, внесенных пользователем А. Для этого после считывания данных пользователем А для их редактирования на эти данные накладывается блокировка. Эта блокировка запрещает доступ к данным со стороны других пользователей до тех пор, пока пользователь А не завершит работу с заблокированными данными и не снимет блокировку.
Этот способ особенно полезен при высокой степени параллельности выполняемых операций с данными или при необходимости всегда просматривать наиболее свежие данные. Такая ситуация обычно возникает в системах оперативного учета материальных запасов или системах учета заказов, когда пользователь для принятия заказа должен убедиться в наличии товаров на складе.
Основными недостатками пессимистического управления параллельностью являются дополнительные накладные расходы на управление блокировками данных, необходимость постоянного подключения к базе данных и недостаточная масштабируемость. Плохая масштабируемость, особенно при работе в распределенной среде (например, в Internet), может привести к блокировке записей на несколько десятков секунд или даже минут.
Второй способ — оптимистическая блокировка (или оптимистическое управление параллельностью) — основан на очень кратковременной блокировке записей во время их фактического обновления. Этот способ решает проблему управления блокировками и масштабируемости, а также прекрасно подходит для редактирования наборов данных, отключенных от базы данных. Но что произойдет, если пользователь Б захочет обновить данные, уже обновленные пользователем А? Один из вариантов решения этой проблемы основан на признании только последнего обновления. Однако этот способ годится только для ограниченного круга приложений.
Для использования оптимистической блокировки нужно определить, изменялись ли данные после их последнего извлечения, что называется нарушением параллельного доступа (concurrency violation). Для этого применяются две основные стратегии.
Первая основана на создании временной метки или уникального номера версии для каждой записи, которые изменяются при обновлении записи. Исходное значение или номер версии включаются в состав предложения WHERE в команде обновления.
Вторая стратегия заключается в сохранении исходных значений полей. Эти значения становятся дополнительными условиями предложения WHERE в команде обновления.
В обоих способах, если исходная запись изменена, условие предложения WHERE не удовлетворяется, запись не будет найдена и не будет обновлена.
НА ЗАМЕТКУ
При использовании оптимистической блокировки в модели ADO 2.X в случае нарушения параллельного доступа появляется сообщение о невозможности найти запись, а не о нарушении параллельного доступа.
В модели ADO.NET поддерживается только оптимистическая блокировка и в текущей версии нет встроенной поддержки пессимистической блокировки. В Visual Studio .NET предусмотрено несколько возможностей для реализации оптимистической блокировки. Эта поддержка находится в полном согласии с расширенной поддержкой распределенных, отключенных и асинхронных приложений.
Команды SQL UPDATE и DELETE, сгенерированные объектом CommandBuilder и программой-мастером Data Adapter Configuration Wizard, содержат предложение WHERE для определения конфликтов параллельного доступа. Рассмотрим более внимательно код из главы 6, "ADO.NET: объект DataAdapter", созданный с помощью программы-мастера Data Adapter Configuration Wizard. Для этого нужно открыть раздел кода с заголовком Windows Form Designer generated code (Код, сгенерированный конструктором Windows Form) в коде формы frmUpdates. Но сначала рассмотрим команду SQL UPDATE, которая приводится в листинге 7.1.
