Подготовленный оператор всегда возвращает значение -2

У меня есть подготовленный оператор слиянием, после выполнения он всегда возвращает -2.

Мой код:

private StringBuilder sb = new StringBuilder();
sb.append("MERGE INTO EMP_BONUS EB USING (SELECT 1 FROM DUAL) on (EB.EMP_id = ?) WHEN MATCHED  THEN  UPDATE SET TA =?,DA=?,TOTAL=?,MOTH=?, NAME=? WHEN NOT MATCHED THEN "
        + "INSERT (EMP_ID, TA, DA, TOTAL, MOTH, NAME)VALUES(?,?,?,?,?,?) ");



public void executes(String threadName) throws Exception {
        ConnectionPro cPro = new ConnectionPro();
        Connection connE = cPro.getConection();

        threadN = threadN + "||" + threadName;

        PreparedStatement pStmt = connE.prepareStatement(sb.toString());
        try {
            count = count + 1;

            for (Employee employeeObj : employee) {

                pStmt.setInt(1, employeeObj.getEmp_id());
            pStmt.setDouble(2, employeeObj.getSalary() * .10);
            pStmt.setDouble(3, employeeObj.getSalary() * .05);
            pStmt.setDouble(4, employeeObj.getSalary()
                    + (employeeObj.getSalary() * .05)
                    + (employeeObj.getSalary() * .10));
            pStmt.setInt(5, count);
            pStmt.setString(6, threadN);
            pStmt.setInt(7, employeeObj.getEmp_id());
            pStmt.setDouble(8, employeeObj.getSalary() * .10);
            pStmt.setDouble(9, employeeObj.getSalary() * .05);
            pStmt.setDouble(10, employeeObj.getSalary()
                    + (employeeObj.getSalary() * .05)
                    + (employeeObj.getSalary() * .10));
            pStmt.setInt(11, count);
            pStmt.setString(12, threadN);    
                pStmt.addBatch();
            }

            int arr[] = pStmt.executeBatch();

            connE.commit();

            System.out.println("Size=" + arr.length);
            if (arr.length != 0) {
                for (int i = 0; i < arr.length; i++) {
                    System.out.println(i + "==" + arr[i]);
                }
            }
        } catch (Exception e) {
             connE.rollback();
            throw e;

        } finally {

            pStmt.close();
            connE.close();

        }
    }

Посмотрите код, в котором подготовленный оператор всегда возвращает значение -2 (все значения внутри массива равны -2) для команд sql, таких как обновление, слияние и т. д., я использовал библиотеку, например ojdbc6.jar, ojdbc5.jar и т. д.


person Anoop    schedule 29.10.2012    source источник
comment
Где оператор SQL, который вы пытаетесь выполнить?   -  person Colin 't Hart    schedule 29.10.2012
comment
Пожалуйста, проверьте это сейчас, я добавил оператор sql.   -  person Anoop    schedule 30.10.2012
comment
Ну, я вижу 12 параметров, которые нужно указать. Вы ставите только 6.   -  person Colin 't Hart    schedule 30.10.2012
comment
Пожалуйста, проверьте это сейчас.....   -  person Anoop    schedule 31.10.2012
comment
Это все еще не работает? Что означает -2?   -  person Colin 't Hart    schedule 31.10.2012


Ответы (1)


Это не сломано.

Если вы прочитали документацию http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#executeBatch%28%29 вы увидите, что executeBatch может вернуть значение SUCCESS_NO_INFO.

Если вы сравните результат, полученный с SUCCESS_NO_INFO, вы увидите, что они одинаковы, то есть SUCCESS_NO_INFO = -2.

Итак, ваш код работал все это время.

person Colin 't Hart    schedule 31.10.2012
comment
Привет, мое намерение состоит в том, чтобы идентифицировать ошибочные строки и повторно обработать их. Но значение SUCCESS_NO_INFO мне в этом не помогает. подготовленный оператор в многопоточности" title="подготовленный оператор в многопоточности"> stackoverflow.com/questions/13048338/ - person Anoop; 31.10.2012
comment
Задайте четкий один вопрос, демонстрирующий вашу проблему. Вопрос должен предоставить все, что нам нужно, чтобы воспроизвести вашу проблему. - person Colin 't Hart; 31.10.2012
comment
И, чтобы уточнить, если все строки в пакете помечены как -2, то, согласно JDBC, все строки были успешными. - person Colin 't Hart; 31.10.2012