Добавляю запись в QueryDataSet и соответственно изменяю БД
Но при этом происходит ошибка
See com.borland.dx.sql.dataset.ResolutionException error code: BASE+1

com.borland.dx.sql.dataset.ResolutionException: An error occurred adding a row to the VSK.SPR_ACCOUNTS table
Как можно посмотреть , какую SQL - команду формирует Jbuilder для добавления новой записи?

Спасибо, но к сожалению JDBC-Oracle не хочет отдавать сведений:
Oracle Jdbc tracing is not avaliable in a non-debug zip/jar file

В догонку - при добавленни записи JDBCMonitor выдает сообщение:
SQLException: SQLState(42000) vendor code(957)

Ну вот я тоже не пробовал, по Вашему совету попробовал, страничка на которую Вы указываете - рассказывает о трудностях применения JDBMonitor. Но узнал кое-что - класс com.borland.jbcl.sql.monitor* работает нормально с драйверами ODBC, с драйверами JDBC - проблема. Но не в этом суть вопроса. Проблема в том, что Borland самостоятельно формирует SQL команду для добавления данных в таблицу БД. У меня SELECT для обновляемой таблицы содержит связь по полю ID_CLI (идентификатор клиента) другой таблицы (SPR_ACCOUNTS).Поэтому JBuilder добавляет запись не только для выбранного набора данных, но и пытается добавить запись в связанный набор данных. Из всего этого возникает вопрос - каким образом посмотреть команду SQL Insert, создаваемую Jbuilder, и по возможности изменить ее (при этом не меняя SELECT для редактируемого DataSet и не создавая новый - без Where)

Спасибо ojdbc14_g - помогло, я вижу 2 Inserta:
JDBC MonitorDRVR SQLS Input SQL: "INSERT INTO VSK.REES_VYD ("ID_CLI","DATE_REE","NUMB_REE","R5","R6","R7","R8","R9","R10","R11","ID_KEY_SHABL","ID_ISP") VALUES (?,?,?,?,?,?,?,?,?,?,?,?)"
DRVR OPER OraclePreparedStatement.setString(paramIndex=1, x=000001ACD2)
...
DRVR SQLS Input SQL: "INSERT INTO VSK.SPR_ACCOUNTS ("NAME_CLI","NAME_CLI") VALUES (?,?)"
DRVR OPER OraclePreparedStatement.setObject(paramIndex=1, object, targetSqlType=1, scale=0)
...Вопрос, а как же все таки исключить второй Insert? И второй - следует ли оставить для дальнейшей работы ojdbc14_g (не повлияет ли это на что-нибуть), или вернуться все таки к ojdbc14?