IDAPI. Сокращение для Integrated Database API (интегрированный прикладной программный интерфейс для работы с базами данных). IDAPI объединяет навигационный доступ к данных (ISAM) и ориентированный на запросы (SQL или QBE) доступ в модель согласованного курсора (consistent cursor model). IDAPI появилось в середине 1994 года и объединяет в себе работу, проделанную техническим комитетом IDAPI (включающим в себя компании Borland, IBM, Novell и Wordperfect). Первый вариант IDAPI был известен как BDE версии 2 (не существовало BDE версии 1, так как ранее она называлась ODA.Pl). Термин "IDAPI" используется не только для того, чтобы сослаться на часть BDE, реализующую API, но и для того, чтобы указать всю технологию целиком. Термин "IDAPI" вытеснил термин "ODAPI", который использовался в ранних реализациях этой технологии.
Identity key(идентифицирующий ключ). Хотя не существует строгого определения этого ключа, идентифицирующий ключ обычно представляет собой суррогатный ключ на основе поля типа INTEGER, которое автоматически заполняется сервером и может предполагать неявное создание лежащею в его основе индекса. Например, и Paradox и MS SqlServei имет специальный тип поля для этих целей InterBase явно не поддерживает такие типы полей, однако тот же самый результат может быть достигнут с помощью полей типа INTEGER, генератора и триггера (с большими усилиями - но и с большей гибкостью). Триггер типа BEFORE INSERT перед вставкой записи в таблицу вызывает функцию gen_id, которая получает следующее значение генератора. Приращение значения генератора может быть не равным единице, как в Paradox.
ISC: Сообщения об ошибках в InterBase начинаются с сочетания букв ISC, и поэтому люди часто спрашивают, что такое ISC. Это не более чем InterBase Software Corporation, наполовину независимая компания, принадлежавшая Borland. В 1998 году она была окончательно поглощена Borland. В конечном счете ISC возродилась в виде Open Source-проекта InterBase - Firebird.
Isolation level(ypoeenb изоляции). Это характеристика транзакции, которая определяет, как одна транзакция должна взаимодействовать с другими транзакциями в той же самой базе данных, в терминах видимости и блокировок. Обычно используются 3 уровня изоляции: Dirty Read (грязное чтение), Read Commited (подтвержденное чтение) и Repeatable Read (повторяющееся чтение). Первый режим является единственным уровнем изоляции в Paradox и поддерживается немногими реляционными СУБД. Второй уровень используется по умолчанию в почти всех реляционных серверах. Третий режим используется по умолчанию в InterBase, и реализован он таким образом, чтобы его использование не ставило сервер "на колени" (что не является фактом для других серверов). Помимо перечисленных уровней изоляции, InterBase предлагает еще более высокий уровень. известный как Repeatable Read with Stability (стабильное повторяющееся Чтение), который может использоваться для специальных и очень коротких транзакций. Благодаря возможности хранить множество версий записей InterBase также позволяет явно контролировать управление блокировками (избежать, ждать или выдать ошибку). Подобный контроль не имеет смысла на других "классических" серверах. (См. главу "Транзакции в InterBase. Параметры транзакций". - прим. авт.).