Компоненти IBDataSet, IBQuery і IBSQL можуть виконувати як статичний, так і динамічний SQL. Динамічний SQL відрізняється від статичного наявністю параметрів. Приклад статичного SQL:
select * from table
where field> 5
Якщо замість цифри 5 передбачається використовувати значення, отримане як введення даних користувачем, то слід використовувати параметризованих запит (ParamCheck: = True):
select * from table
where field>: param
Двокрапка або символ '?' означають, що запит передбачає завдання параметра. Робиться це в такий спосіб:
IBQuery.SQL.Clear; // очистити текст sql
IBQuery.SQL.Add ( 'select * from table where field>: param'); // задати текст запиту
IBQuery.Prepare; // відправити запит на сервер, перевірити його коректність і т.п.
IBQuery.ParamByName ( 'param'). AsInteger: = 5; // задати значення параметра
IBQuery.Open; // або IBQuery.ExecSQL
Для статичних запитів виклик Prepare необов'язковий - компонент сам його виконає автоматично, якщо Prepare ні викликаний.
примітка. після Prepare можна звернутися до властивості Plan, тому що саме після Prepare сервер повідомляє план виконання запиту.
Prepare дуже зручний при періодичному виконанні одного і того ж запиту, з різними значеннями параметра. При цьому Prepare викликається один раз, а установка параметрів і виклик ExecQuery проводиться стільки раз, скільки потрібно. Найчастіше такий спосіб використовується для запитів Insert і Update.
імена параметрів підтримуються тільки клієнтської бібліотекою. Тобто, сервер розуміє параметри тільки у вигляді символу '?'. Якщо компоненти вміють обробляти іменовані параметри, то вони перед відправкою запиту на сервер "вирізають" їх, відправляючи туди запит виду
select * from table
Деякі бібліотеки компонент можуть не підтримувати або некоректно обробляти запити, в яких використовується два або більше параметрів з однаковим ім'ям.
фільтрація
Можливо, в BDE або іншому використовуваному вами до IBX наборі компонент доступу до БД ви активно застосовували фільтрацію записів. Загалом фільтрація в IBX працює практично так само, як і в BDE.
Для цього компонента у властивості Filter повинні бути описані умови фільтрації так, як ніби ви додаєте умова where до звичайного запиту SQL. IBTable сконструює запит, використовуючи заданий в TableName ім'я таблиці, додасть як where умова фільтрації з Filter, і додасть конструкцію ORDER BY якщо вказана "сортування" результуючого набору за допомогою властивостей IndexFieldNames або IndexName. Тому, в Filter повинен бути зазначений текст з урахуванням всіх особливостей синтаксису InterBase або Firelbird. наприклад
У підсумку запит, що відсилається на сервер, матиме вигляд
select id, LastName, FirstName.
where LastName like 'A%'
IbDataSet, ibQuery
Ці компоненти виконують запити, чітко задані у властивостях SelectSQL або SQL. Тому додаткова фільтрація можлива тільки методом OnFilterRecord.
OnFilterRecord
Компоненти IBTable, IBDataSet і IBQuery дозволяють використовувати цю подію для фільтрації записів. На відміну від IBTable, де у властивості Filter можна вказати додаткову умову відбору для запиту, виконуваного на сервері, OnFilterRecord визначає "видимість" записи, вже прийнятої DataSet-му з сервера. Метод має два параметри - DataSet, тобто що за компонент запросив фільтрацію (для можливості отримання даних з "поточної" записи), і Accept, який визначає, показувати даний запис підключеному компоненту DataSource чи ні. Для того, щоб імітувати фільтрацію, показану вище на прикладі для IBTable, в OnFilterRecord потрібно написати приблизно наступне:
Accept: = (DataSet.FieldByName ( 'LastName'). AsString> = 'A') and
(DataSet.FieldByName ( 'LastName'). AsString <'B');
Пам'ятайте, що фільтрація проводиться в локальному буфері вже прийнятих з сервера записів. Тобто, якщо в програмі передбачається невелике число варіантів фільтрації, то можливо, має сенс зменшити навантаження на клієнтську частину і при зміні фільтра конструювати запит для SelectSQL з необхідною умовою where (точно так само як це робить IBTable, тільки рядок where ви будете додавати до тексту запиту самостійно).