Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Вебмастеру -> Сеппа Д. -> "Microsoft ADO.NET" -> 176

Microsoft ADO.NET - Сеппа Д.

Сеппа Д. Microsoft ADO.NET — М.: Русская Редакция, 2003. — 640 c.
ISBN 5-7502-0223-2
Скачать (прямая ссылка): mcrsftado2003.pdf
Предыдущая << 1 .. 170 171 172 173 174 175 < 176 > 177 178 179 180 181 182 .. 260 >> Следующая

ADO, предшественница ADO.NET, генерирует динамические обновления отдельных записей. При передаче обновлений ADO исключала из запросов INSERT поля, значения которых не изменялись. Таким образом, новые записи БД, создаваемые средствами ADO, автоматически содержат значения по умолчанию, а записи, создаваемые средствами ADO.NET — нет.
В случае с ADO.NET простейшее решение — добавить в приложение код, который при создании новой записи автоматически определял бы значения полей по умолчанию.
ГЛАВА
11
Сложные случаи обновления данных
т>
13 глазе 10 рассказывалось о передаче изменений в БД с использованием функций обновления, предоставляемых объектом DataAdapter. Вы научились генерировать логику обновления средствами мастера Data Adapter Configuration Wizard и объекта CommandBititder. Кроме того, теперь вы понимаете структуру SQL-запросов UPDATE, UNSERT и DELETE, генерируемых этими утилитами для преобразования отложенных изменений, хранящихся в объекте DaiaSiri, в изменения содержимого БД.
Примеры главы 10 представляют собой простые случаи обновления данных: все попытки обновления завершались успешно и :;сс,::я передачи изменений не требовалось заново выбирать из БД какую-либо информацию. Таблицы, задействованные во фрагментах кода, не содержат столбцов с генерируемыми сервером данными (например, значения автоинкремента или значения типа times!;' mp). и изменения всегда передаются в одну таблицу, Тем не менее в приложениях, скорее всего, реализуются более сложные случаи обновления данных,
Так, при работе с таблицами, включающими столбцы с автоинкрементом, вероятно, вам потребуется получать значения автоинкремента, генерируемые БД для новых записей. В других случаях вам может понадобиться повторно выбрать содержимое записи после передачи обновлений БД, например при оптимистичном управлении параллелизмом на основе полей типа timestamp.
Чем сложнее приложение, тем сложнее возможные ситуации обновления данных. Например, непросто передать изменения иерархичных данных. С многоуровневыми приложениями связаны проблемы иного рода — например, передача объектов DataSet, содержащих только необходимые для передачи обновлений в, БД данные, и повторная интеграция только что выбранных значений типа time-stamp и автоинкремента в имеющийся объект DataSet.
ГЛАВА Сложные случаи обновления данных 405
Попытки опткшнстичпсго обновления не всегда завершаются успешно. они завершается ошибкой, если другой пользователь успел изменить нужные вам записи. Рекомендую вам научиться изящно разрешать такие проблемы вместо того, чтобы пытаться любой ценой избежать их возникновения,
В этой главе подробно рассматриваются эти и другие сложные случаи обновления. Однако здесь я несколько изменил манеру изложения. Предыдущие главы изобилуют фрагментами \:< >.>а, которые можно копировать и вставлять в консольные приложения и затем, ничего не изменяя, успешно их выполнять. Создать похожий полнофункциональный кода для сложных случаев юновления. обсуждаемых
в этой главе, нереально. Поэтому здесь показаны небольшие фрагменты кода
приложений, записанных на прилагаемом к книге компакт-диске.
Обновление отображаемого содержимого записи после передачи изменений
В главе 10 рассказывалось о создании и использовании запросов INSERT, UPDATE и DELETE для передачи изменений в БД. По сути, эти запросы — улица с односторонним движением. БД изменяет содержимое записи на основе переданной в запросе информации, И хотя она сообщает о числе обработанных запросом записей, новое содержимое измененных записей БД не возвращает,
Иногда требуется, чтобы передача обновлений в БД походила на улицу с двухсторонним движением. Как рассказывалось в главе i1. предотвратить ненамеренную перезапись одним пользователем изменений другого пользователя удается при помощи типа данных timestamp Microsoft SQL Server. Когда содержимое записи изменяется. БД генерирует для нее новое значение поля типа timestamp. Рассмотрим следующую ситуацию.
Ваше приложение отображает содержимое заказа. Пользователь добавляет в заказ новый товар, соответствующий одной из записей вашей таблицы, аналогичной таблице OrderDetaUs БД Northwind. Тем не менее в таблице есть поле типа timestamp, значение которого используется в логике обновления. Когда пользователь добавляет новый заказанный товар в БД. та генерирует для новой записи
новое значение поля timestamp. Здесь все нормально.
Теперь предположим, что клиентская часть приложения использует windows, а не Web-интерфейс. После того как пользователь передаст в БД новый заказанный товар, приложение по-прежнему отображает содержимое заказа. Что, если пользователю требуется изменить запись об этом же товаре и снова передать изменение в БД?
Как вы помните, логика обновления объекта DaioAiicp*?; использует значение поля timestamp в свойстве UpdateCommana.Up^ вставке новой записи БД генерирует для нее новое значение поля timestamp. Если этого значения не окажется 'в объекте DalaRow, попытка обновления завершится неудачно.
Аналогичная проблема возникает, если вы, изменив запись, передадите это изменение в БД, и затем снова попытаетесь изменить эту же запись. При внесении первого изменения БД новое значение поля timestamp. Если это значение не передать каким-либо способов в объект DataRow, вторая попытка обновления завершится ошибкой.
Предыдущая << 1 .. 170 171 172 173 174 175 < 176 > 177 178 179 180 181 182 .. 260 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100