Delphi 3 и создание приложений баз данных

       

Изменяемые TQuery


Записи НД, возвращаемые компонентом TQuery, могут изменяться, подобно тому, как это происходит в компоненте TTable. Записи можно редактировать в компоненте TDBGrid, связанном с TQuery (метод автоматического перевода НД в состояния dsInsert, dsEdit, автоматического выполнения методов Insert, Edit, Delete, Post и Cancel). Также может применяться метод программного формирования значения полей записи, ввода таких значений с использованием компонента TDBEdit, TDBCheckBox и других. В этом случае методы Insert, Edit, Delete, Post и Cancel вызываются в программе явно .

Возможность изменения НД, возвращаемого после выполнения оператора SELECT, определяется свойством property CanModify: Boolean; Значение этого свойства устанавливается автоматически, исходя из определенных факторов. Если в процессе выполнения свойство CanModify установлено в True, набор данных доступен для изменения. При значении False записи НД не могут быть добавлены, изменены или удалены.

Свойство CanModify всегда устанавливается в False, если в False установлено свойство RequestLive компонента TQuery: property RequestLive: Boolean; Значение данного свойства может быть установлено как во время проектирования, так и во время разработки приложения. По умолчанию всегда устанавливается False (НД доступен только для чтения). Однако установка данного свойства в значение True (НД может быть изменен) вовсе не означает, что НД действительно будет позволено изменяться и что свойство CanModify будет установлено в True. Это произойдет только в том случае, если синтаксис оператора SELECT при выполнении запроса будет признан "верным".

Синтаксис оператора SELECT будет признан "неверным", если:

• НД формируется более чем из одной ТБД;

• присутствует предложение принудительной сортировки результирующего набора данных ORDER BY;

• значения хотя бы одного столбца результирующего НД сформировано с использованием агрегатных функций (SUM, COUNT, AVG, MIN, MAX);

• при доступе к СУБД Sybase в таблице отсутствует уникальный индекс

В том случае, если свойство RequestLive установлено в True, а синтаксис оператора SELECT признан "неверным":

• возвращается НД, доступный только для чтения - при доступе к таблицам локальных СУБД (Paradox, dBase);

• выдается ошибка - при доступе к серверным СУБД (InterBase, Oracle) и т.д.

Если изменения, внесенные в НД методами Post, Delete, не отображаются в НД, его содержимое можно обновить методом procedure Refresh; Однако в этом случае оператор SELECT должен быть выполнен для таблицы локальной СУБД и эта таблица должна иметь уникальный индекс. Для НД, возвращенных в результате выполнения запроса к удаленной СУБД, выполнение метода Refresh не влечет за собой никаких последствий.

Для случая работы с удаленными БД следует избегать выполнения изменений при помощи методов Insert, Edit, Delete записей в НД, полученного при помощи TQuery. В этом случае вся нагрузка на модификацию удаленных Таблиц ложится на клиентское приложение, в то время как в соответствии с одним из краеугольных камней идеологии "клиент-сервер" - вся тяжесть операций по физическому доступу к БД должна ложиться на сервер БД.



Предотвратить ввод записей, не удовлетворяющих условиям, перечисленным в предложении WHERE оператора SELECT, можно путем установки в True значения свойства

property Constrained: Boolean;

Например, для НД, полученного по запросу

SELECT *

FROM RASHOD

WHERE KOLVO > 1000

при Constrained, установленном в True, будут блокироваться попытки запоминания записей со значением поля KOLVO, меньшим 1000.

В том случае, если НД доступен только для чтения, его записи могут быть изменены при помощи SQL-операторов INSERT, UPDATE, DELETE. При этом изменения в НД не отображаются Для отображения изменений НД следует переоткрыть, выполнив метод Close и повторно Open. Повторное открытие НД устанавливает указатель текущей записи на первую строку, что удобно далеко не всегда. В этом случае можно

1) вносить изменения в НД пакетом, визуализируя их путем его повторного открытия после равных порций изменений - например, после каждых 10 изменений, этот метод больше подходит для случаев значительного количества изменений в НД;

2) реализовать в форме локатор - механизм поиска записи, удовлетворяющей некоторому условию (значение условия можно вводить, например, в компонент TEdit или группу компонентов TEdit или автоматически помещать туда значения полей, однозначно идентифицирующих запись, для последней добавленной или измененной записи). Поиск реализуется при нажатии экранной кнопки. Для поиска используется метод Locate, например:

procedure TForm1.LocatorButtonClick(Sender: TObject);

begin

RashodQuery.Locate('N_RASH',Editl.Text, [loPartialKey]);

end;

3) перед повторным открытием НД запоминать значение поля (полей), однозначно идентифицирующего запись, и после открытия восстанавливать местоположение указателя текущей записи при помощи метода Locate.

Например,

пусть в набор данных (компонент RashodQuery) добавляются записи при помощи SQL-оператора INSERT (компонент InsertQuery). Однозначно идентифицирует запись в НД RashodQuery поле 'М'. Тогда восстановление указателя текущей записи после повторного открытия НД RashodQuery может быть реализован так:

TmpN_Rash := FieldByName('М').Aslnteger;

InsertQuery.ExecSQL;

RashodQuery.Close;

RashodQuery.Open;

RashodQuery.Locate('М',TmpN_Rash, []);

Заметим, что такой подход не годится для случая удаления записей при помощи SQL-оператора DELETE, поскольку после удаления в НД не существует записи с запомненным значением уникального поля (полей).



Содержание раздела