При этом если вы передаете в VALUES данные для BLOB В виде текста, Firebird примет символьную строку в качестве ввода, например:

INSERT INTO ATABLE (BLOBMEMO)

VALUES ('Now is the time for all good men to come to the aid of the party');

Эта возможность будет подходящей при условии, что сохраняемый текст никогда не превысит 32 767 байтов (или 32 765, если вы помещаете поле VARCHAR в BLOB). Может показаться, что для многих интерфейсов программирования подобная проблема не существует, потому что они не могут обрабатывать такие большие строки. Однако, поскольку Firebird принимает выражения конкатенации строк SQL, такие как MYVARCHARI 11 MYVARCHAR2, следует принять меры по защите входных строк от переполнения.

В приложениях со встроенным SQL (ESQL) возможно конструирование оператора SQL для добавления целого массива в столбец массива. Могут появиться ошибки, если данные не полностью заполняют массив.

В DSQL вовсе нет возможности добавлять данные в столбцы массивов. Необходимо реализовывать пользовательский метод в приложении или в коде компонента, который будет вызывать API-функцию isc_array_put_siice.

Определение таблицы может содержать столбцы, чьи значения автоматически заполняются данными при добавлении новой строки. Это может происходить в нескольких случаях:

* столбец определен с предложением COMPUTED BY;

* столбец или домен, на котором он основан, включает предложение DEFAULT;

* для таблицы был создан триггер BEFORE INSERT для автоматического заполнения столбца.

Автоматические поля могут воздействовать на тот способ, каким вы формулируете операторы INSERT для таблицы.

Включение вычисляемого столбца в список входных столбцов является неверным и приводит к исключениям, как показано в следующем примере:

CREATE TABLE EMPLOYEE (

EMP_NO INTEGER NOT NULL PRIMARY KEY,

FIRST_NAME VARCHAR (15),

LAST_NAME VARCHAR(20),

BIRTH_COUNTRY VARCHAR(30) DEFAULT 'TAIWAN',

FULL_NAME COMPUTED BY FIRST_NAME || ' ' || LAST_NAME);

COMMIT;

INSERT INTO EMPLOYEE (EMP_NO, FIRST_NAME, LAST_NAME, FULL_NAME)

VALUES (99, 'Jiminy', 'Cricket', 'Jiminy Cricket');

Если столбец определен со значением по умолчанию, то это значение будет работать только при добавлении и только если этот столбец отсутствует в списке входных столбцов. Если немного изменить оператор добавления в предыдущем примере, то в столбец BIRTH_COUNTRY будет записано значение 'TAIWAN':

INSERT INTO EMPLOYEE (EMP_NO, FIRST_NAME, LAST_NAME)

VALUES (99, 'Jiminy', 'Cricket');

COMMIT;

SELECT * FROM EMPLOYEE WHERE EMP_NO = 99;

EMP_NO FIRST_NAME LAST_NAME BIRTH_COUNTRY FULL_NAME

99 Jiminy Cricket TAIWAN Jiminy Cricket

Значения по умолчанию никогда не заменяют значений NULL:

INSERT INTO EMPLOYEE (EMP_NO, FIRST_NAME, LAST_NAME, BI RTH_COUNTRY)

VALUES (100, 'Maria', 'Callas', NULL);

COMMIT;

SELECT * FROM EMPLOYEE WHERE EMP_NO = 100;

EMP_NO FIRST_NAME LAST_NAME BIRTH_COUNTRY FULL_NAME

100 Maria Callas Maria Callas

Если вы разрабатываете приложения с использованием компонентов, которые генерируют операторы INSERT из спецификаций столбцов операторов SELECT для наборов данных - например, Delphi или JBuilder - учитывайте такое поведение, Если ваш компонент не поддерживает метод получения значений по умолчанию с сервера, может оказаться необходимым изменить оператор, записывающий данные.

При добавлении данных в таблицу, для которой существуют триггеры, автоматически заполняющие некоторые столбцы, убедитесь, что вы не задали эти столбцы в вашем входном списке, если вы хотите, чтобы триггер выполнил свою работу.

Это вовсе не означает, что вы всегда должны опускать поля, обрабатываемые триггером, во входном списке. Очень рекомендуется для поддержания целостности данных создавать триггеры, которые присваивают значения столбцам в случае, когда такие значения не задаются в операторе INSERT - особенно когда используется множество приложений и инструментов для доступа к вашей базе данных. Триггер должен проверять входное значение (например, NULL) и выполнять свои действия в соответствии с условиями.