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
===============
</screen>
   </para>
  </sect2>

  <sect2 id="ecpg-sqlstate-sqlcode">
   <title><literal>SQLSTATE</literal> vs. <literal>SQLCODE</literal></title>

   <para>
    The fields <literal>sqlca.sqlstate</literal> and
    <literal>sqlca.sqlcode</literal> are two different schemes that
    provide error codes.  Both are derived from the SQL standard, but
    <literal>SQLCODE</literal> 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
    <literal>SQLSTATE</literal>.
   </para>

   <para>
    <literal>SQLSTATE</literal> is a five-character array.  The five
    characters contain digits or upper-case letters that represent
    codes of various error and warning conditions.
    <literal>SQLSTATE</literal> 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
    <literal>00000</literal>.  The <literal>SQLSTATE</literal> codes are for
    the most part defined in the SQL standard.  The
    <productname>PostgreSQL</productname> server natively supports
    <literal>SQLSTATE</literal> error codes; therefore a high degree
    of consistency can be achieved by using this error code scheme
    throughout all applications.  For further information see
    <xref linkend="errcodes-appendix"/>.
   </para>

   <para>
    <literal>SQLCODE</literal>, 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 <productname>PostgreSQL</productname> has assigned
    some specific <literal>SQLCODE</literal> 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
    <literal>SQLSTATE</literal> scheme, the corresponding
    <literal>SQLSTATE</literal> 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
    <literal>SQLSTATE</literal> listing in <xref linkend="errcodes-appendix"/>
    in each case.
   </para>

   <para>
    These are the assigned <literal>SQLCODE</literal> values:

    <variablelist>
     <varlistentry id="ecpg-sqlstate-sqlcode-ecpg-no-error">
      <term>0 (<symbol>ECPG_NO_ERROR</symbol>)</term>
      <listitem>
       <para>
        Indicates no error. (SQLSTATE 00000)
      </para>
     </listitem>
    </varlistentry>

    <varlistentry id="ecpg-sqlstate-sqlcode-ecpg-not-found">
     <term>100 (<symbol>ECPG_NOT_FOUND</symbol>)</term>
     <listitem>
      <para>
       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)
      </para>

      <para>
       When processing a cursor in a loop, you could use this code as
       a way to detect when to abort the loop, like this:
<programlisting>
while (1)
{
    EXEC SQL FETCH ... ;
    if (sqlca.sqlcode == ECPG_NOT_FOUND)
        break;
}
</programlisting>
       But <literal>WHENEVER NOT FOUND DO BREAK</literal> effectively
       does this internally, so there is usually no advantage in
       writing this