Sql error 42804

Sql error 42804 error

This section describes how you can handle exceptional conditions and warnings in an embedded SQL program. There are two nonexclusive facilities for this.

• Callbacks can be configured to handle warning and error conditions using the WHENEVER command.
• Detailed information about the error or warning can be obtained from the sqlca variable.

36.8.1. Setting Callbacks

One simple method to catch errors and warnings is to set a specific action to be executed whenever a particular condition occurs. In general:

condition can be one of the following:

The specified action is called whenever an error occurs during the execution of an SQL statement.

The specified action is called whenever a warning occurs during the execution of an SQL statement.

The specified action is called whenever an SQL statement retrieves or affects zero rows. (This condition is not an error, but you might be interested in handling it specially.)

action can be one of the following:

This effectively means that the condition is ignored. This is the default.

GOTO label
GO TO label

Jump to the specified label (using a C goto statement).

Print a message to standard error. This is useful for simple programs or during prototyping. The details of the message cannot be configured.

Call exit(1) , which will terminate the program.

Execute the C statement break . This should only be used in loops or switch statements.

Execute the C statement continue . This should only be used in loops statements. if executed, will cause the flow of control to return to the top of the loop.

CALL name ( args )
DO name ( args )

Call the specified C functions with the specified arguments. (This use is different from the meaning of CALL and DO in the normal PostgreSQL grammar.)

The SQL standard only provides for the actions CONTINUE and GOTO (and GO TO ).

Here is an example that you might want to use in a simple program. It prints a simple message when a warning occurs and aborts the program when an error happens:

The statement EXEC SQL WHENEVER is a directive of the SQL preprocessor, not a C statement. The error or warning actions that it sets apply to all embedded SQL statements that appear below the point where the handler is set, unless a different action was set for the same condition between the first EXEC SQL WHENEVER and the SQL statement causing the condition, regardless of the flow of control in the C program. So neither of the two following C program excerpts will have the desired effect:

36.8.2. sqlca

For more powerful error handling, the embedded SQL interface provides a global variable with the name sqlca (SQL communication area) that has the following structure:

(In a multithreaded program, every thread automatically gets its own copy of sqlca . This works similarly to the handling of the standard C global variable errno .)

sqlca covers both warnings and errors. If multiple warnings or errors occur during the execution of a statement, then sqlca will only contain information about the last one.

If the last SQL statement was successful, then sqlca.sqlerrd[1] contains the OID of the processed row, if applicable, and sqlca.sqlerrd[2] contains the number of processed or returned rows, if applicable to the command.

In case of an error or warning, sqlca.sqlerrm.sqlerrmc will contain a string that describes the error. The field sqlca.sqlerrm.sqlerrml contains the length of the error message that is stored in sqlca.sqlerrm.sqlerrmc (the result of strlen() , not really interesting for a C programmer). Note that some messages are too long to fit in the fixed-size sqlerrmc array; they will be truncated.

In case of a warning, sqlca.sqlwarn[2] is set to W . (In all other cases, it is set to something different from W .) If sqlca.sqlwarn[1] is set to W , then a value was truncated when it was stored in a host variable. sqlca.sqlwarn[0] is set to W if any of the other elements are set to indicate a warning.

The fields sqlcaid , sqlabc , sqlerrp , and the remaining elements of sqlerrd and sqlwarn currently contain no useful information.

The structure sqlca is not defined in the SQL standard, but is implemented in several other SQL database systems. The definitions are similar at the core, but if you want to write portable applications, then you should investigate the different implementations carefully.

Here is one example that combines the use of WHENEVER and sqlca , printing out the contents of sqlca when an error occurs. This is perhaps useful for debugging or prototyping applications, before installing a more “ user-friendly ” error handler.

The result could look as follows (here an error due to a misspelled table name):

36.8.3. SQLSTATE vs. SQLCODE

The fields sqlca.sqlstate and sqlca.sqlcode are two different schemes that provide error codes. Both are derived from the SQL standard, but SQLCODE has been marked deprecated in the SQL-92 edition of the standard and has been dropped in later editions. Therefore, new applications are strongly encouraged to use SQLSTATE .

SQLSTATE is a five-character array. The five characters contain digits or upper-case letters that represent codes of various error and warning conditions. SQLSTATE has a hierarchical scheme: the first two characters indicate the general class of the condition, the last three characters indicate a subclass of the general condition. A successful state is indicated by the code 00000 . The SQLSTATE codes are for the most part defined in the SQL standard. The PostgreSQL server natively supports SQLSTATE error codes; therefore a high degree of consistency can be achieved by using this error code scheme throughout all applications. For further information see Appendix A.

SQLCODE , the deprecated error code scheme, is a simple integer. A value of 0 indicates success, a positive value indicates success with additional information, a negative value indicates an error. The SQL standard only defines the positive value +100, which indicates that the last command returned or affected zero rows, and no specific negative values. Therefore, this scheme can only achieve poor portability and does not have a hierarchical code assignment. Historically, the embedded SQL processor for PostgreSQL has assigned some specific SQLCODE values for its use, which are listed below with their numeric value and their symbolic name. Remember that these are not portable to other SQL implementations. To simplify the porting of applications to the SQLSTATE scheme, the corresponding SQLSTATE is also listed. There is, however, no one-to-one or one-to-many mapping between the two schemes (indeed it is many-to-many), so you should consult the global SQLSTATE listing in Appendix A in each case.

These are the assigned SQLCODE values:

Indicates no error. (SQLSTATE 00000)

This is a harmless condition indicating that the last command retrieved or processed zero rows, or that you are at the end of the cursor. (SQLSTATE 02000)

When processing a cursor in a loop, you could use this code as a way to detect when to abort the loop, like this:

But WHENEVER NOT FOUND DO BREAK effectively does this internally, so there is usually no advantage in writing this out explicitly.

Indicates that your virtual memory is exhausted. The numeric value is defined as -ENOMEM . (SQLSTATE YE001)

Indicates the preprocessor has generated something that the library does not know about. Perhaps you are running incompatible versions of the preprocessor and the library. (SQLSTATE YE002)

This means that the command specified more host variables than the command expected. (SQLSTATE 07001 or 07002)

This means that the command specified fewer host variables than the command expected. (SQLSTATE 07001 or 07002)

This means a query has returned multiple rows but the statement was only prepared to store one result row (for example, because the specified variables are not arrays). (SQLSTATE 21000)

The host variable is of type int and the datum in the database is of a different type and contains a value that cannot be interpreted as an int . The library uses strtol() for this conversion. (SQLSTATE 42804)

The host variable is of type unsigned int and the datum in the database is of a different type and contains a value that cannot be interpreted as an unsigned int . The library uses strtoul() for this conversion. (SQLSTATE 42804)

The host variable is of type float and the datum in the database is of another type and contains a value that cannot be interpreted as a float . The library uses strtod() for this conversion. (SQLSTATE 42804)

The host variable is of type numeric and the datum in the database is of another type and contains a value that cannot be interpreted as a numeric value. (SQLSTATE 42804)

The host variable is of type interval and the datum in the database is of another type and contains a value that cannot be interpreted as an interval value. (SQLSTATE 42804)

The host variable is of type date and the datum in the database is of another type and contains a value that cannot be interpreted as a date value. (SQLSTATE 42804)

The host variable is of type timestamp and the datum in the database is of another type and contains a value that cannot be interpreted as a timestamp value. (SQLSTATE 42804)

This means the host variable is of type bool and the datum in the database is neither ‘t’ nor ‘f’ . (SQLSTATE 42804)

The statement sent to the PostgreSQL server was empty. (This cannot normally happen in an embedded SQL program, so it might point to an internal error.) (SQLSTATE YE002)

A null value was returned and no null indicator variable was supplied. (SQLSTATE 22002)

An ordinary variable was used in a place that requires an array. (SQLSTATE 42804)

The database returned an ordinary variable in a place that requires array value. (SQLSTATE 42804)

The value could not be inserted into the array. (SQLSTATE 42804)

The program tried to access a connection that does not exist. (SQLSTATE 08003)

The program tried to access a connection that does exist but is not open. (This is an internal error.) (SQLSTATE YE002)

The statement you are trying to use has not been prepared. (SQLSTATE 26000)

Duplicate key error, violation of unique constraint (Informix compatibility mode). (SQLSTATE 23505)

The descriptor specified was not found. The statement you are trying to use has not been prepared. (SQLSTATE 33000)

The descriptor index specified was out of range. (SQLSTATE 07009)

An invalid descriptor item was requested. (This is an internal error.) (SQLSTATE YE002)

During the execution of a dynamic statement, the database returned a numeric value and the host variable was not numeric. (SQLSTATE 07006)

During the execution of a dynamic statement, the database returned a non-numeric value and the host variable was numeric. (SQLSTATE 07006)

A result of the subquery is not single row (Informix compatibility mode). (SQLSTATE 21000)

Some error caused by the PostgreSQL server. The message contains the error message from the PostgreSQL server.

The PostgreSQL server signaled that we cannot start, commit, or rollback the transaction. (SQLSTATE 08007)

The connection attempt to the database did not succeed. (SQLSTATE 08001)

Duplicate key error, violation of unique constraint. (SQLSTATE 23505)

A result for the subquery is not single row. (SQLSTATE 21000)

An invalid cursor name was specified. (SQLSTATE 34000)

Transaction is in progress. (SQLSTATE 25001)

There is no active (in-progress) transaction. (SQLSTATE 25P01)

An existing cursor name was specified. (SQLSTATE 42P03)

Submit correction

If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.

Copyright © 1996-2023 The PostgreSQL Global Development Group

Источник

Sql error 42804 error

В этом разделе описывается, как можно обрабатывать исключительные условия и предупреждения в программе со встраиваемым SQL. Для этого предназначены два средства, которые могут дополнять друг друга.

• Можно настроить функции-обработчики для обработки предупреждений и ошибок, воспользовавшись командой WHENEVER .
• Подробную информацию об ошибке или предупреждении можно получить через переменную sqlca .

33.8.1. Установка обработчиков

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

Здесь условие может быть следующим:

Указанное действие вызывается, когда при выполнении оператора SQL происходит ошибка. SQLWARNING

Указанное действие вызывается, когда при выполнении оператора SQL выдаётся предупреждение. NOT FOUND

Указанное действие вызывается, когда оператор SQL получает или обрабатывает ноль строк. (Это обстоятельство не считается ошибкой, но бывает полезно отследить его.)

действие может быть следующим:

Это фактически означает, что условие игнорируется. Это поведение по умолчанию. GOTO метка
GO TO метка

Перейти к указанной метке (используя оператор goto языка C). SQLPRINT

Вывести сообщение в устройство стандартного вывода. Это полезно для простых программ или при разработке прототипов. Содержание этого сообщения не настраивается. STOP

Вызвать exit(1) , что приведёт к завершению программы. DO BREAK

Выполнить оператор break языка C. Этот вариант следует использовать только в циклах или операторах switch . CALL имя ( аргументы )
DO имя ( аргументы )

Вызвать указанные функции C с заданными аргументами.

В стандарте SQL описаны только действия CONTINUE и GOTO (и GO TO ).

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

Оператор EXEC SQL WHENEVER является директивой препроцессора SQL, а не оператором языка C. Устанавливаемое им действие при ошибках или предупреждениях применяется ко всем встраиваемым операторам SQL ниже точки, где устанавливается обработчик, если только это действие не было изменено после первой команды EXEC SQL WHENEVER , и до SQL-оператора, вызвавшего это условие, вне зависимости от хода выполнения программы на C. Поэтому обе следующие программы на C не дадут желаемого эффекта:

33.8.2. sqlca

Для более гибкой обработки ошибок в интерфейсе встраиваемого SQL представлена глобальная переменная с именем sqlca (SQL Communication Area, Область сведений SQL), имеющая следующую структуру:

(В многопоточной программе каждый поток автоматически получает собственную копию sqlca . Это работает подобно стандартной в C глобальной переменной errno .)

Структура sqlca покрывает и предупреждения, и ошибки. Если в процессе выполнения оператора выдаётся несколько предупреждений или ошибок, sqlca будет содержать сведения только о последнем(ей) из них.

Если последний оператор SQL был успешным, в sqlca.sqlerrd[1] содержится OID обработанной строки (если это уместно), а в sqlca.sqlerrd[2] количество обработанных или возвращённых строк (если это уместно для команды).

В случае ошибки или предупреждения sqlca.sqlerrm.sqlerrmc будет содержать строку, описывающую ошибку. Поле sqlca.sqlerrm.sqlerrml содержит длину сообщения об ошибке, которое хранится в sqlca.sqlerrm.sqlerrmc (результат функции strlen() , который не очень интересен для программиста C). Заметьте, что некоторые сообщения могут не умещаться в массив sqlerrmc фиксированного размера; они будут обрезаться.

В случае предупреждения, в sqlca.sqlwarn[2] записывается символ W . (Во всех других случаях значение будет отличным от W .) Символ W в sqlca.sqlwarn[1] показывает, что значение было обрезано при сохранении в переменной среды. W в sqlca.sqlwarn[0] устанавливается, если предупреждение отмечается в каком-либо другом элементе массива.

Поля sqlcaid , sqlabc , sqlerrp и остальные элементы sqlerrd и sqlwarn в настоящее время не содержат полезной информации.

Структура sqlca не определена в стандарте SQL, но реализована в нескольких других СУБД SQL. Принципиально она определяется одинаково, но если вы хотите, чтобы ваши приложения были переносимыми, тщательно изучите различия реализаций.

В следующем примере, демонстрирующем применение WHENEVER в сочетании с sqlca , выводится содержимое sqlca при возникновении ошибки. Это может быть полезно для отладки или в прототипах, пока не реализован более « дружественный пользователю » обработчик ошибок.

Результат может выглядеть следующим образом (при ошибке, вызванной опечаткой в имени таблицы):

33.8.3. SQLSTATE и SQLCODE

Поля sqlca.sqlstate и sqlca.sqlcode отражают две различные схемы, представляющие коды ошибок. Обе схемы пришли из стандарта SQL, но схема SQLCODE была признана устаревшей в редакции SQL-92 и исключена в последующих редакциях. Поэтому в новых приложениях настоятельно рекомендуется использовать SQLSTATE .

SQLSTATE задаётся в массиве из пяти символов. Эти пять символов содержат цифры или буквы в верхнем регистре, представляющие коды различных условий ошибок и предупреждений. SQLSTATE определяется по иерархической схеме: первые два символа обозначают общий класс условия, а следующие три — подкласс общего условия. Успешное состояние обозначается кодом 00000 . По большей части коды SQLSTATE определены в стандарте SQL. Сервер PostgreSQL поддерживает коды ошибок SQLSTATE естественным образом; поэтому используя во всех приложениях именно эту схему кодов ошибок, можно добиться высокой степени согласованности. За дальнейшими сведениями обратитесь к Приложению A.

SQLCODE — устаревшая схема, в которой коды ошибок представлены просто целыми числами. Значение 0 обозначает успешное завершение, положительное значение — успешное завершение с дополнительной информацией, а отрицательное говорит об ошибке. В стандарте SQL определено только положительное значение +100, показывающее, что последняя команда вернула или затронула ноль строк, но отрицательные значения не определены. Таким образом, с этой схемой нельзя рассчитывать на переносимость и она не имеет иерархической структуры. Исторически сложилось, что процессор встраиваемого SQL для PostgreSQL назначает некоторые определённые значения SQLCODE для собственного использования; они перечислены ниже с числовыми значениями и символьными именами. Помните, что эти коды несовместимы с другими реализациями SQL. Поэтому для упрощения перевода приложений на схему SQLSTATE вместе с этими кодами перечисляются соответствующие значения SQLSTATE . Однако однозначного соответствия один-к-одному или один-ко-многим между этими двумя схемами не существует (на самом деле это соответствие многие-ко-многим), поэтому следует свериться со списком SQLSTATE в Приложении A в каждом случае.

SQLCODE может принимать следующие значения:

Показывает, что ошибки нет. (SQLSTATE 00000) 100 ( ECPG_NOT_FOUND )

Это нейтральное условие, показывающее, что последняя команда вернула или обработала ноль строк, либо курсор достиг конца. (SQLSTATE 02000)

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

Но WHENEVER NOT FOUND DO BREAK внутри по сути делает это же, поэтому такое явное условие обычно ничем не лучше. -12 ( ECPG_OUT_OF_MEMORY )

Указывает, что закончилась виртуальная память. Числовое значение определено как -ENOMEM . (SQLSTATE YE001) -200 ( ECPG_UNSUPPORTED )

Указывает, что препроцессор сгенерировал код, который не понимает библиотека. Возможно, вы используете несовместимые версии препроцессора и библиотеки. (SQLSTATE YE002) -201 ( ECPG_TOO_MANY_ARGUMENTS )

Это означает, что в команде было указано больше переменных среды, чем она ожидает. (SQLSTATE 07001 или 07002) -202 ( ECPG_TOO_FEW_ARGUMENTS )

Это означает, что в команде было указано меньше переменных среды, чем она ожидает. (SQLSTATE 07001 или 07002) -203 ( ECPG_TOO_MANY_MATCHES )

Это означает, что запрос вернул несколько строк, но оператор был подготовлен только для одной строки результата (например, потому что переданные переменные — не массивы). (SQLSTATE 21000) -204 ( ECPG_INT_FORMAT )

Переменная среды типа int и данные в базе имеют разные типы, и в этих данных содержится значение, которое нельзя преобразовать в int . Для этого преобразования библиотека использует функцию strtol() . (SQLSTATE 42804) -205 ( ECPG_UINT_FORMAT )

Переменная среды типа unsigned int и данные в базе имеют разные типы, и в этих данных содержится значение, которое нельзя преобразовать в unsigned int . Для этого преобразования библиотека использует функцию strtoul() . (SQLSTATE 42804) -206 ( ECPG_FLOAT_FORMAT )

Переменная среды типа float и данные в базе имеют разные типы, и в этих данных содержится значение, которое нельзя преобразовать во float . Для этого преобразования библиотека использует функцию strtod() . (SQLSTATE 42804) -207 ( ECPG_NUMERIC_FORMAT )

Переменная среды типа numeric и данные в базе имеют разные типы, и в этих данных содержится значение, которое нельзя преобразовать в numeric . (SQLSTATE 42804) -208 ( ECPG_INTERVAL_FORMAT )

Переменная среды типа interval и данные в базе имеют разные типы, и в этих данных содержится значение, которое нельзя преобразовать в interval . (SQLSTATE 42804) -209 ( ECPG_DATE_FORMAT )

Переменная среды типа date и данные в базе имеют разные типы, и в этих данных содержится значение, которое нельзя преобразовать в date . (SQLSTATE 42804) -210 ( ECPG_TIMESTAMP_FORMAT )

Переменная среды типа timestamp и данные в базе имеют разные типы, и в этих данных содержится значение, которое нельзя преобразовать в timestamp . (SQLSTATE 42804) -211 ( ECPG_CONVERT_BOOL )

Это означает, что переменная среды имеет тип bool , а значение в базе данных отличается от ‘t’ или ‘f’ . (SQLSTATE 42804) -212 ( ECPG_EMPTY )

Серверу PostgreSQL был передан пустой оператор. (Этого обычно не должно происходить в программе со встраиваемым SQL, так что это может указывать на внутреннюю ошибку.) (SQLSTATE YE002) -213 ( ECPG_MISSING_INDICATOR )

Возвращено значение NULL, но переменная-индикатор NULL не задана. (SQLSTATE 22002) -214 ( ECPG_NO_ARRAY )

Там, где требуется массив, была передана обычная переменная. (SQLSTATE 42804) -215 ( ECPG_DATA_NOT_ARRAY )

База данных возвратила обычную переменную там, где требуется значение-массив. (SQLSTATE 42804) -216 ( ECPG_ARRAY_INSERT )

Не удалось вставить значение в массив. (SQLSTATE 42804) -220 ( ECPG_NO_CONN )

Программа попыталась использовать несуществующее подключение. (SQLSTATE 08003) -221 ( ECPG_NOT_CONN )

Программа попыталась использовать подключение, которое существует, но не было открыто. (Это внутренняя ошибка.) (SQLSTATE YE002) -230 ( ECPG_INVALID_STMT )

Оператор, который вы пытаетесь выполнить, не был подготовлен. (SQLSTATE 26000) -239 ( ECPG_INFORMIX_DUPLICATE_KEY )

Ошибка повторяющегося ключа, нарушение ограничения уникальности (режим совместимости с Informix). (SQLSTATE 23505) -240 ( ECPG_UNKNOWN_DESCRIPTOR )

Указанный дескриптор не найден. Оператор, который вы пытаетесь использовать, не был подготовлен. (SQLSTATE 33000) -241 ( ECPG_INVALID_DESCRIPTOR_INDEX )

Указанный индекс дескриптора вне диапазона. (SQLSTATE 07009) -242 ( ECPG_UNKNOWN_DESCRIPTOR_ITEM )

Запрошен неверный элемент дескриптора. (Это внутренняя ошибка.) (SQLSTATE YE002) -243 ( ECPG_VAR_NOT_NUMERIC )

При выполнении динамического оператора база данных возвратила числовое значение, тогда как переменная среды — не числовая. (SQLSTATE 07006) -244 ( ECPG_VAR_NOT_CHAR )

При выполнении динамического оператора база данных возвратила не числовое значение, тогда как переменная среды — числовая. (SQLSTATE 07006) -284 ( ECPG_INFORMIX_SUBSELECT_NOT_ONE )

Результат подзапроса представлен не одной строкой (режим совместимости с Informix). (SQLSTATE 21000) -400 ( ECPG_PGSQL )

Ошибка произошла на стороне сервера PostgreSQL . В тексте ошибки содержится сообщение об ошибке от сервера PostgreSQL . -401 ( ECPG_TRANS )

Сервер PostgreSQL сообщает, что клиент не может запускать, фиксировать или отменять транзакцию. (SQLSTATE 08007) -402 ( ECPG_CONNECT )

Попытка подключения к базе данных была неудачной. (SQLSTATE 08001) -403 ( ECPG_DUPLICATE_KEY )

Ошибка повторяющегося ключа, нарушение ограничения уникальности. (SQLSTATE 23505) -404 ( ECPG_SUBSELECT_NOT_ONE )

Результат подзапроса представлен не одной строкой. (SQLSTATE 21000) -602 ( ECPG_WARNING_UNKNOWN_PORTAL )

Указано неверное имя курсора. (SQLSTATE 34000) -603 ( ECPG_WARNING_IN_TRANSACTION )

Транзакция в процессе выполнения. (SQLSTATE 25001) -604 ( ECPG_WARNING_NO_TRANSACTION )

Нет активной (выполняющейся) транзакции. (SQLSTATE 25P01) -605 ( ECPG_WARNING_PORTAL_EXISTS )

Было указано имя существующего курсора. (SQLSTATE 42P03)

Источник

One simple method to catch errors and warnings is to set a specific action to be executed whenever a particular condition occurs. In general:

EXEC SQL WHENEVER condition action;

condition can be one of the following:

action can be one of the following:

The SQL standard only provides for the actions CONTINUE and GOTO (and GO TO).

Here is an example that you might want to use in a simple program. It prints a simple message when a warning occurs and aborts the program when an error happens:

EXEC SQL WHENEVER SQLWARNING SQLPRINT;
EXEC SQL WHENEVER SQLERROR STOP;

The statement EXEC SQL WHENEVER is a directive of the SQL preprocessor, not a C statement. The error or warning actions that it sets apply to all embedded SQL statements that appear below the point where the handler is set, unless a different action was set for the same condition between the first EXEC SQL WHENEVER and the SQL statement causing the condition, regardless of the flow of control in the C program. So neither of the two following C program excerpts will have the desired effect:

/*
 * WRONG
 */
int main(int argc, char *argv[])
{
    ...
    if (verbose) {
        EXEC SQL WHENEVER SQLWARNING SQLPRINT;
    }
    ...
    EXEC SQL SELECT ...;
    ...
}

/*
 * WRONG
 */
int main(int argc, char *argv[])
{
    ...
    set_error_handler();
    ...
    EXEC SQL SELECT ...;
    ...
}

static void set_error_handler(void)
{
    EXEC SQL WHENEVER SQLERROR STOP;
}

For more powerful error handling, the embedded SQL interface provides a global variable with the name sqlca (SQL communication area) that has the following structure:

struct
{
    char sqlcaid[8];
    long sqlabc;
    long sqlcode;
    struct
    {
        int sqlerrml;
        char sqlerrmc[SQLERRMC_LEN];
    } sqlerrm;
    char sqlerrp[8];
    long sqlerrd[6];
    char sqlwarn[8];
    char sqlstate[5];
} sqlca;

(In a multithreaded program, every thread automatically gets its own copy of sqlca. This works similarly to the handling of the standard C global variable errno.)

sqlca covers both warnings and errors. If multiple warnings or errors occur during the execution of a statement, then sqlca will only contain information about the last one.

If no error occurred in the last SQL statement, sqlca.sqlcode will be 0 and sqlca.sqlstate will be "00000". If a warning or error occurred, then sqlca.sqlcode will be negative and sqlca.sqlstate will be different from "00000". A positive sqlca.sqlcode indicates a harmless condition, such as that the last query returned zero rows. sqlcode and sqlstate are two different error code schemes; details appear below.

If the last SQL statement was successful, then sqlca.sqlerrd[1] contains the OID of the processed row, if applicable, and sqlca.sqlerrd[2] contains the number of processed or returned rows, if applicable to the command.

In case of an error or warning, sqlca.sqlerrm.sqlerrmc will contain a string that describes the error. The field sqlca.sqlerrm.sqlerrml contains the length of the error message that is stored in sqlca.sqlerrm.sqlerrmc (the result of strlen(), not really interesting for a C programmer). Note that some messages are too long to fit in the fixed-size sqlerrmc array; they will be truncated.

In case of a warning, sqlca.sqlwarn[2] is set to W. (In all other cases, it is set to something different from W.) If sqlca.sqlwarn[1] is set to W, then a value was truncated when it was stored in a host variable. sqlca.sqlwarn[0] is set to W if any of the other elements are set to indicate a warning.

The fields sqlcaid, sqlabc, sqlerrp, and the remaining elements of sqlerrd and sqlwarn currently contain no useful information.

The structure sqlca is not defined in the SQL standard, but is implemented in several other SQL database systems. The definitions are similar at the core, but if you want to write portable applications, then you should investigate the different implementations carefully.

Here is one example that combines the use of WHENEVER and sqlca, printing out the contents of sqlca when an error occurs. This is perhaps useful for debugging or prototyping applications, before installing a more “user-friendly” error handler.

EXEC SQL WHENEVER SQLERROR CALL print_sqlca();

void
print_sqlca()
{
    fprintf(stderr, "==== sqlca ====n");
    fprintf(stderr, "sqlcode: %ldn", sqlca.sqlcode);
    fprintf(stderr, "sqlerrm.sqlerrml: %dn", sqlca.sqlerrm.sqlerrml);
    fprintf(stderr, "sqlerrm.sqlerrmc: %sn", sqlca.sqlerrm.sqlerrmc);
    fprintf(stderr, "sqlerrd: %ld %ld %ld %ld %ld %ldn", sqlca.sqlerrd[0],sqlca.sqlerrd[1],sqlca.sqlerrd[2],
                                                          sqlca.sqlerrd[3],sqlca.sqlerrd[4],sqlca.sqlerrd[5]);
    fprintf(stderr, "sqlwarn: %d %d %d %d %d %d %d %dn", sqlca.sqlwarn[0], sqlca.sqlwarn[1], sqlca.sqlwarn[2],
                                                          sqlca.sqlwarn[3], sqlca.sqlwarn[4], sqlca.sqlwarn[5],
                                                          sqlca.sqlwarn[6], sqlca.sqlwarn[7]);
    fprintf(stderr, "sqlstate: %5sn", sqlca.sqlstate);
    fprintf(stderr, "===============n");
}

The result could look as follows (here an error due to a misspelled table name):

==== sqlca ====
sqlcode: -400
sqlerrm.sqlerrml: 49
sqlerrm.sqlerrmc: relation "pg_databasep" does not exist on line 38
sqlerrd: 0 0 0 0 0 0
sqlwarn: 0 0 0 0 0 0 0 0
sqlstate: 42P01
===============

The fields sqlca.sqlstate and sqlca.sqlcode are two different schemes that provide error codes. Both are derived from the SQL standard, but SQLCODE has been marked deprecated in the SQL-92 edition of the standard and has been dropped in later editions. Therefore, new applications are strongly encouraged to use SQLSTATE.

SQLSTATE is a five-character array. The five characters contain digits or upper-case letters that represent codes of various error and warning conditions. SQLSTATE has a hierarchical scheme: the first two characters indicate the general class of the condition, the last three characters indicate a subclass of the general condition. A successful state is indicated by the code 00000. The SQLSTATE codes are for the most part defined in the SQL standard. The PostgreSQL server natively supports SQLSTATE error codes; therefore a high degree of consistency can be achieved by using this error code scheme throughout all applications. For further information see Appendix A.

SQLCODE, the deprecated error code scheme, is a simple integer. A value of 0 indicates success, a positive value indicates success with additional information, a negative value indicates an error. The SQL standard only defines the positive value +100, which indicates that the last command returned or affected zero rows, and no specific negative values. Therefore, this scheme can only achieve poor portability and does not have a hierarchical code assignment. Historically, the embedded SQL processor for PostgreSQL has assigned some specific SQLCODE values for its use, which are listed below with their numeric value and their symbolic name. Remember that these are not portable to other SQL implementations. To simplify the porting of applications to the SQLSTATE scheme, the corresponding SQLSTATE is also listed. There is, however, no one-to-one or one-to-many mapping between the two schemes (indeed it is many-to-many), so you should consult the global SQLSTATE listing in Appendix A in each case.

These are the assigned SQLCODE values: