Sql error 42704

[{«Product»:{«code»:»SS9S6B»,»label»:»IBM Cognos Controller»},»Business Unit»:{«code»:»BU059″,»label»:»IBM Software w/o TPS»},»Component»:»—«,»Platform»:[{«code»:»PF033″,»label»:»Windows»}],»Version»:»10.3.1;10.3;10.2.1;10.2.0″,»Edition»:»»,»Line of Business»:{«code»:»LOB10″,»label»:»Data and AI»}}]

I don’t get it. When you create a table in DB2, do you have to do anything extra to it to make it so you can do a select on it? I run my Java program with a specified name of a table which has been in the database for a long time. But then I change one single variable, the table name, and it gives me the 42704 error meaning it can’t find the table. The problem is I open up Rapid SQL and can see the table that I created but it still gives me the 42704 error when I try to use it in my code. Here’s what I’m talking about:
——————————————————
<?xml version=»1.0″ encoding=»UTF-8″ ?>

<!DOCTYPE sqlMap
PUBLIC «-//ibatis.apache.org//DTD SQL Map 2.0//EN»
«http://ibatis.apache.org/dtd/sql-map-2.dtd»>

<sqlMap namespace=»daemon»>

<resultMap id=»result» class=»Daemon»>
<result property=»username» columnIndex=»2″ jdbcType=»VARCHAR» javaType=»java.lang.String»/>
</resultMap>

<parameterMap id=»param» class=»Daemon»>
<parameter property=»username»/>
</parameterMap>

<select id=»getUsername» resultClass = «String» resultMap = «result»>
select * from <tableName>
</select>
</sqlMap>
——————————————————————
So when tableName is the table that’s always been in the database, it works fine. But when I change it to the table name I created, it doesn’t work. But yet the column and data types are all the same. Any ideas? Here’s the method I’m using to call it.
————————————————————————-
public Daemon getUsername () throws SQLException
{
return (Daemon) (sqlMapper.queryForObject(«getUsername»));
}
———————————————————————————
Here’s the error:

There is an exception: com.ibatis.common.jdbc.exception.NestedSQLException:
— The error occurred in ..\Daemon.xml.
— The error occurred while applying a parameter map.
— Check the getUsername-InlineParameterMap.
— Check the statement (query failed).
— Cause: com.ibm.db2.jcc.c.SqlException: DB2 SQL error: SQLCODE: -204, SQLSTATE: 42704, SQLERRMC: APPSFA.DUMMYTEST

Here is the stack trace:

com.ibatis.common.jdbc.exception.NestedSQLException:
— The error occurred in ..\Daemon.xml.
— The error occurred while applying a parameter map.
— Check the getUsername-InlineParameterMap.
— Check the statement (query failed).
— Cause: com.ibm.db2.jcc.c.SqlException: DB2 SQL error: SQLCODE: -204, SQLSTATE: 42704, SQLERRMC: APPSFA.DUMMYTEST
at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:185)
at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryForObject(GeneralStatement.java:104)
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:566)
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:541)
at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForObject(SqlMapSessionImpl.java:106)
at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForObject(SqlMapSessionImpl.java:110)
at com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryForObject(SqlMapClientImpl.java:87)
at Caller.getUsername(Caller.java:63)
at MainClass.main(MainClass.java:32)
Caused by: com.ibm.db2.jcc.c.SqlException: DB2 SQL error: SQLCODE: -204, SQLSTATE: 42704, SQLERRMC: APPSFA.DUMMYTEST
at com.ibm.db2.jcc.c.kh.c(kh.java:1660)
at com.ibm.db2.jcc.c.kh.d(kh.java:1648)
at com.ibm.db2.jcc.c.kh.a(kh.java:1205)
at com.ibm.db2.jcc.b.db.g(db.java:139)
at com.ibm.db2.jcc.b.db.a(db.java:39)
at com.ibm.db2.jcc.b.t.a(t.java:34)
at com.ibm.db2.jcc.b.sb.f(sb.java:142)
at com.ibm.db2.jcc.c.kh.m(kh.java:1176)
at com.ibm.db2.jcc.c.lh.bb(lh.java:1941)
at com.ibm.db2.jcc.c.lh.d(lh.java:2383)
at com.ibm.db2.jcc.c.lh.U(lh.java:1401)
at com.ibm.db2.jcc.c.lh.execute(lh.java:1385)
at com.ibatis.sqlmap.engine.execution.SqlExecutor.executeQuery(SqlExecutor.java:186)
at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.sqlExecuteQuery(GeneralStatement.java:205)
at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:173)
… 8 more

Did I leave anything important out?

Hi Laurenz, I’m running postgresql under ubuntu and i’m trying migration with oracle_fdw but I stopped facing an issue creating a foreign table. Could You help me?
I compiled oracle_fwd 1.5 (2.0 was giving me dependencies issues) and succesfully installed extension on my ubuntu.
Following instructions I create the foreign server:
CREATE SERVER oradb FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver '//10.10.20.100:1521/GDBT');
I granted user postgres:
GRANT USAGE ON FOREIGN SERVER oradb TO postgres;
then I created user mapping:
CREATE USER MAPPING FOR postgres SERVER oradb OPTIONS (user 'UTENTE', password 'pwd');
now I’m trying to create a foreing table:

CREATE FOREIGN TABLE test 
  (oid integer NOT NULL,id varchar(80),lon numeric,lat numeric,h numeric,descr varchar(80),job varchar(80),shape geometry(Point,3003))
SERVER oradb OPTIONS (table 'TEST');

but i’m getting the following error:

ERROR: server "oradb" does not exist
SQL state: 42704

What am I doing wrong?

note1: I can retrieve foreign server by;
SELECT srvname,srvoptions FROM pg_foreign_server;
getting:
oradb {dbserver=//10.10.20.100:1521/GDBT}
and foreign connection detail:
SELECT oracle_diag('oradb')
getting:
oracle_fdw 1.5.0, PostgreSQL 9.3.4, Oracle client 12.2.0.1.0, Oracle server 11.2.0.4.0

note2: I can succefully connect to oracle by sqlplus:
sqlplus UTENTE/pwd@//10.10.20.100:1521/GDBT
having access to TEST table:

SQL> desc TEST
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 OBJECTID                                  NOT NULL NUMBER(38)
 ID                                                 NVARCHAR2(80)
 LON                                                NUMBER(38,8)
 LAT                                                NUMBER(38,8)
 H                                                  NUMBER(38,8)
 DESC_                                              NVARCHAR2(80)
 JOB                                                NVARCHAR2(80)
 SHAPE                                              SDE.ST_GEOMETRY

note3: I’m currently using other foreign tables with postgres_fdw extension

Postgresql sql error 42704

Всем сообщениям, которые выдаёт сервер Postgres Pro , назначены пятисимвольные коды ошибок, соответствующие кодам « SQLSTATE » , описанным в стандарте SQL. Приложения, которые должны знать, какое условие ошибки имело место, обычно проверяют код ошибки и только потом обращаются к текстовому сообщению об ошибке. Коды ошибок, скорее всего, не изменятся от выпуска к выпуску Postgres Pro , и они не меняются при локализации как сообщения об ошибках. Заметьте, что отдельные, но не все коды ошибок, которые выдаёт Postgres Pro , определены стандартом SQL; некоторые дополнительные коды ошибок для условий, не описанных стандартом, были добавлены независимо или позаимствованы из других баз данных.

Согласно стандарту, первые два символа кода ошибки обозначают класс ошибок, а последние три символа обозначают определённое условие в этом классе. Таким образом, приложение, не знающее значение определённого кода ошибки, всё же может понять, что делать, по классу ошибки.

В Таблице A.1 перечислены все коды ошибок, определённые в Postgres Pro 9.5.20.1. (Некоторые коды в настоящее время не используются, хотя они определены в стандарте SQL.) Также показаны классы ошибок. Для каждого класса ошибок имеется « стандартный » код ошибки с последними тремя символами 000 . Этот код выдаётся только для таких условий ошибок, которые относятся к некоторому классу, но не имеют более определённого кода.

Символ, указанный в столбце « Имя условия » , определяет условие в PL/pgSQL . Имена условий могут записываться в верхнем или нижнем регистре. (Заметьте, что PL/pgSQL , в отличие от ошибок, не распознаёт предупреждения; то есть классы 00, 01 и 02.)

Для некоторых типов ошибок сервер сообщает имя объекта базы данных (таблица, столбец таблицы, тип данных или ограничение), связанного с ошибкой; например, имя уникального ограничения, вызвавшего ошибку unique_violation . Такие имена передаются в отдельных полях сообщения об ошибке, чтобы приложениям не пришлось извлекать его из возможно локализованного текста ошибки для человека. На момент выхода PostgreSQL 9.3 полностью охватывались только ошибки класса SQLSTATE 23 (нарушения ограничений целостности), но в будущем должны быть охвачены и другие классы.

Таблица A.1. Коды ошибок Postgres Pro

Источник

Postgresql sql error 42704

All messages emitted by the PostgreSQL server are assigned five-character error codes that follow the SQL standard’s conventions for “ SQLSTATE ” codes. Applications that need to know which error condition has occurred should usually test the error code, rather than looking at the textual error message. The error codes are less likely to change across PostgreSQL releases, and also are not subject to change due to localization of error messages. Note that some, but not all, of the error codes produced by PostgreSQL are defined by the SQL standard; some additional error codes for conditions not defined by the standard have been invented or borrowed from other databases.

According to the standard, the first two characters of an error code denote a class of errors, while the last three characters indicate a specific condition within that class. Thus, an application that does not recognize the specific error code might still be able to infer what to do from the error class.

Table A.1 lists all the error codes defined in PostgreSQL 15.1. (Some are not actually used at present, but are defined by the SQL standard.) The error classes are also shown. For each error class there is a “ standard ” error code having the last three characters 000 . This code is used only for error conditions that fall within the class but do not have any more-specific code assigned.

The symbol shown in the column “ Condition Name ” is the condition name to use in PL/pgSQL . Condition names can be written in either upper or lower case. (Note that PL/pgSQL does not recognize warning, as opposed to error, condition names; those are classes 00, 01, and 02.)

For some types of errors, the server reports the name of a database object (a table, table column, data type, or constraint) associated with the error; for example, the name of the unique constraint that caused a unique_violation error. Such names are supplied in separate fields of the error report message so that applications need not try to extract them from the possibly-localized human-readable text of the message. As of PostgreSQL 9.3, complete coverage for this feature exists only for errors in SQLSTATE class 23 (integrity constraint violation), but this is likely to be expanded in future.

Table A.1. PostgreSQL Error Codes

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.

Источник