Эльчин Азиз Али оглы Азизов
дата публикации 22-05-2001 00:00 Немного об использовании ADO в Delphi. ( часть 2 )
Я полагаю, что те, кто читают эти строки могут написать небольшую программку на Delphi, подключающуюся к базе данных с использованием ADO и имеют некоторое представление о языке SQL?
Если это не так у Вас есть три выбора
- - все равно читать эту статью дальше - поскольку ничего особо сложного в ней нет
- - перейти первой части и прочитать ее и все документы, на которые там имеются ссылки, а потом вернуться сюда
- - нажать Alt+F4
Я рад, что Вы остались здесь - тогда продолжим. :-)
Для изучения я приготовил небольшой примерчик - это примитивная база данных Access 2000, состоящая из двух таблиц, такой вот структуры:
Первая таблица - воображаемые телефонные абоненты - в ней четыре поля - автоинкрементный код абонента, его имя, телефонный номер, и код выхода на междугороднюю линию - по умолчанию этому полю присваивается значение 8.
Вторая таблица служит для хранения информации о воображаемых междугородних звонках абонентов - здесь хранятся дата и время звонка, его продолжительность, код набранного города и набранный номер.
Таблица абонентов связанна с таблицей звонков по полю AbonentID отношением один ко многим.
В этой части мы будем работать только с первой из этих двух таблиц - про вторую пока можно не вспоминать.
Примечание 1:
гуру SQL Server несомненно признали в этой картинке диаграмму из Enterprise Manager - я воспользовался им просто для наглядности, на самом деле база Access - хотя перенести ее на SQL Server не составит никакого труда.
Примечание 2:
nvarchar - тип который не поддерживает BDE - одна из причин перехода на ADO.
Как я уже, кажется, говорил ADO всегда работает по принципу клиент/сервер - даже если Вы открываете локальную таблицу на своем компьютере. Это хорошо конечно, но иногда может сбить с толку, если не разобраться что именно происходит «за кулисами».
А происходит там следующее. Начнем с простого случая - пусть программа открывает только одну таблицу - Abonents - и позволяет пользователю добавлять новых абонентов и вносить исправления.
Как только мы открываем таблицу Abonents, кроме самих данных, из базы извлекаются еще и метаданные. Метаданные - это «данные о данных» т.е. имена таблиц, полей и самое главное, информация о том, какие из полей являются ключевыми (в нашем случае ключевое поле - AbonentID).
Эта информация (полученные метаданные) - позволяют движку ADO (ADO cursor engine) преобразовывать действия пользователя в команды SQL, посылаемые серверу.
Предположим пользователь добавил абонента.
На сервер будет отправлена приблизительно такая команда:
INSERT INTO Abonents … список имен полей… список значений…
А теперь пользователь исправил фамилию одного из абонентов.
На сервер отправится что-то вроде:
Update Abonent Set Name = 'Сидоров' where AbonentID = 5.
Теперь становится понятным, почему нужны поля с первичным ключем - иначе движок ADO не имел бы ни малейшего понятия - как ему найти на сервере строку, которую надо изменить.
А откуда cursor engine знает, что первичный ключ таблиц Abonents - это поле AbonentID? Правильно - он знает об этом благодаря метаданным, которые были получены при открытии таблицы.
А что если первичного ключa все-таки нет? Тогда cursor engine пытается найти строку, включив раздел Where все остальные, не ключевые поля, и если при этом будет изменена не одна строка а несколько (предположим в базе были однофамильцы с одинаковыми телефонами) - вы получите предупреждение, о том что изменилось несколько строк, а не одна, но, увы, будет уже поздновато:-)
Примечание 1:
Если кому интересно внешний вид этого сообщения имеется в этой статье http://www.delphikingdom.com/mastering/ado.htm - точнее это вторая картинка сверху.
Примечание 2:
OLE DB Provider for Oracle обновляет данные без использования первичного ключа - используя Row ID
Пока все нормально, но предположим Вы - не единственный пользователь базы данных, и кто-то еще успел изменить данные до Вас. Что произойдет?
Ведь тогда команда
Update Abonent Set Name = 'Сидоров' where AbonentID = 5.
просто-напросто запишет Ваш вариант изменений поверх чужого. Хорошо если это просто фамилия - а если это сумма? Кто-то добавил к этой сумме 100 долларов, а вы, не зная об этом - вписали 10? А если это была сумма, которую Вам должны заплатить? Не пойдет! Тут на арену выходит первое из динамических свойств - Update Criteria.
Но прежде пара слов - о том это за динамические свойства такие. Они динамические, потому что их можно изменять после того, как набор данных ADO уже открыт, доступ к ним осуществляется по имени через свойство Properties, например вот так:
ADODataSet1.Properties['имя свойства'].Value:=< новое значение свойства>
Итак, первое свойство, о котором мы поговорим, называется Update Criteria - оно может принимать следующие значения
| adCriteriaKey | В строку Where включается только значения полей, состовляющих первичный ключ |
| adCriteriaAllCols | В строку Where включается значения всех полей, которые были выбраны при открытии набора данных командой Select |
| adCriteriaUpdCols | В строку Where включается значения только тех полей, которые были изменены пользователем. Это значение принято по умолчанию |
| adCriteriaTimeStamp | Это значение можно использовать если у вас есть поле типа TimeStamp - в строку Where включается значение такого поля, в результате если Вы попытаетесь изменить строку в таблице позже того, как ее изменил кто-то другой - получите сообщение об ошибке. |
|
Внимательный читатель конечно уже поймал меня на маленькой хитрости - так как значение свойства по умолчанию adCriteriaUpdCols - значит мне не удастся вписать 10 долларов если кто-то уже вписал 100 - я получу сообщение об ошибке.
Хорошо, а как Cursor Engine узнает - удалось ему исправить строку или нет? Очень просто - сервер возвращает ему в ответ на команду цифру - число строк, которые были затронуты командой (number of rows affected).
Если эта цифра не равна единице - система считает, что произошел конфликт, связанный с оптимистической блокировкой при конкурирующем обновлении и выдает сообщение об ошибке «Row cannot be located for updating и т.д.» (Строка для обновления не найдена)
Все вроде ясно - но тут есть одна тонкость. Разработчики баз данных SQL Server'а часто используют так называемые триггеры - специальные SQL команды, которые могут срабатывать при добавлении или изменении данных в таблице, с которой Вы работаете. В результате Ваша программа может получить значение number of rows affected вовсе не после Вашей команды, а после команды, запущенной триггером. И если Ваша команда сработала и успешно изменила запись, но триггер выполнил какую-то другую команду, которая не изменила ни одной записи к Вам придет значение number of rows affected равное нулю и выскочит сообщение об ошибке которой на самом деле не было. Что же делать, как говаривал Достоевский? (вопрос «Кто виноват» опустим) Я могу предложить такой вариант выхода - во всех триггерах первой строчкой всегда пишите команду SET NOCOUNT ON - это заставит SQL Server не считать число строк, затронутых командами триггера - и вы, таким образом, будите получать правильное значение rows affected.
Следующее свойство, о котором я хотел рассказать, называется Update Resync. Итак, после того как мы добавляем или изменяем строку, изменения записываются на сервер. Но бывают ситуации, когда сервер сам добавляет кое-что к вновь введенным данным. Самый распространенный случай - в строке есть поле типа Identity (автоинкрементное) - значение которого устанавливается сервером. Другие случаи - поля со значениями по умолчанию (если такому полю ничего не присвоить - его значение будет установлено сервером), поля типа TimeStamp (при каждом изменении строки в это поле сервер записывает время изменения с точностью до миллисекунд). Кроме того, запись, которую Вы добавили или обновили, может быть изменена сработавшим триггером.
Посмотрите на нашу табличку Abonents. Как видите у нее есть поле со значение по умолчанию (поле Code принимает значение по умолчанию 8).
Теперь вообразите такой сценарий:
- - пользователь добавляет нового абонента, не указав код выхода на междугороднюю линию
- - сервер вписывает в поле Code новой записи значение 8, о котором наша программа не знает
- - пользователь вспоминает, что забыл ввести нестандартной код выхода на междугороднюю линию, и редактирует вновь добавленную запись, вписав в поле Code значение 9
Стоп. Посмотрим, что тут произойдет. Так как значение свойства Update Criteria по умолчанию равно adCriteriaUpdCols на сервер будет отправлена команда вида:
Update Abonents Set Code = '9' where AbonentID = 15 AND Code IS NULL
Все верно - передается ключевое поле и исходное значение того поля которое надо изменить, но это исходное значение должно быть равно 8! Наша программа не знала о том, что сервер вписал значение по умолчанию - в результате мы получим сообщение об ошибке «Не удается найти строку для обновления. Некоторые значения могли быть изменены со времени последнего чтения». Некоторые Delphi программисты предлагают обновлять весь набор данных после каждого изменения - по-моему это не очень элегантный способ - ведь нужно обновить только одну строку! Но как?
Для этого то и предназначено свойство Update Resync. Вот список его возможных значений:
| adResyncNone | Никаких обновлений данных на стороне клиента после добавления или изменения не производится |
| adResyncAutoIncrement | После добавления новых строк считывается значение автоинкрементного поля (новое Identity)
Это значение Update Resync принято по умолчанию
|
| adResyncUpdates | После изменения строки - измененная строка тут же считывается с сервера |
| adResyncInserts | После добавления строки новая строка сразу же считывается с сервера |
| adResyncConflicts | В случае ошибки, связанной с конфликтом при конкурирующим обновлении с сервера считывается значение строки, вызвавшей конфликт |
| adResyncAll | Комбинация из всех возможных значений свойства Update Resync |
|
Примечание:
вообще я от души не советую связываться с Access 97 - если есть выбор - лучше выбрать Access 2000 или Paradox. Чтоб не быть голословным - Access 97 не поддерживает блокировку на уровне строк - поэтому Access 2000 и Paradox однозначно лучше.
Вопрос на засыпку - какое значение нужно установить свойству Update Resync в нашем примере, чтобы при добавлении абонента сразу же считывалось значение по умолчанию поля Code?
- Верный ответ - ADODataSet1.Properties['Update Resync'].Value:= adResyncAutoIncrement + adResyncInserts;
- Другой верный ответ - или adResyncAll
ADODataSet1.Properties['Update Resync'].Value:= adResyncInserts + adResyncInserts;
Примечание:
устанавливайте adResyncInserts только в комбинации одновременно с adResyncAutoIncrement - иначе Вы перестанете получать значения Identity для вновь добавленных полей.
В результате сразу после добавления нового абонента cursor engine сперва считает значение AbonentId которое получила вновь добавленная строка, а зачем, считает с сервера строку, используя полученное значение AbonentId - таким образом мы сразу увидим все изменения которые сервер произвел над нашей новой строкой и переоткрывать набор данных не понадобится.
Я написал небольшую программку, позволяющую по играться со свойством Update Resync вот ее внешний вид:
Вы можете скачать ее и поэкспериментировать - добавьте нового абонента, не внося его код, а потом исправьте код во вновь добавленной записи. Вы получите сообщение об ошибке.
Попробуйте сделать то же самое, установив adResyncInserts - ошибка не должна появляться.
Несколько слов о свойстве adResyncConflicts. В случае если Вы пытаетесь изменить запись, которую уже изменили до Вас - и установлено Update Criteria равное adResyncConflicts с сервера считываются значения полей записи, вызвавшей конфликт и помещаются в свойство Underlying Values каждого элемента масcива Fields соответствующего Recordset.
Не совсем по-русски звучит? Ну тогда скажу на Delphi:
for i:= 0 to ADODataSet1.Recordset.Fields.Count-1 do
begin
ADODataSet1.Recordset.Fields[i].UnderlyingValue;
{это актуальные, хранящиеся в настоящий момент, а не в
момент открытия набора данных значения каждого i-того поля,
записи которая вызвала конфликт}
end;
Обратите внимание как в моей прораммке-примере отлавливается событие RecordChangeComplete - если на этом событии переменная Reason равна erUndoUpdate - это значит, что нужно отменить изменения - что я и пытаюсь сделать - но сработает это только если Update Criteria равно adResyncConflicts.
На этом пока все.
прADOлжение следует...
JINX,
22 мая 2001г.
Специально для Королевства Delphi
К материалу прилагаются файлы:
[ADO]
 Обсуждение материала [ 05-10-2010 00:24 ] 22 сообщения |
