Error ora 01427 single row subquery returns more than one row

There’re two error patterns related to ORA-01427 described in this post:

1. SELECT with Equal Operator
2. Job Failed by Trigger.

I will talk about them respectively in the following sections. In which, the first error pattern is very common and easy to solve. But the second one is not so obvious, you need more patience to solve it.

A. ORA-01427 in SELECT with Equal Operator

If SQL engine expects your subquery to return a single row, it may throw ORA-01427 when the subquery returns more than one row unexpectedly. For example:

SQL> select * from employees where department_id = (select department_id from departments where location_id = 1700);
select * from employees where department_id = (select department_id from departments where location_id = 1700)
                                               *
ERROR at line 1:
ORA-01427: single-row subquery returns more than one row

This is because the subquery in the SELECT statement returned more than one row for the predicate department_id, which does not comply with a singular value limited operator, the equal =. Consequently, the statement fails to continue and then throw ORA-01427 to notify developers.

Solutions

It’s just like that we wanted strictly only one item, but eventually it returned more than we expected.

1. Using IN Operator

Then what operator is used to prevent ORA-01427 in SELECT statement? In practice, SELECT should use IN operator instead of = (equal operator) in order to accommodate more than one row returned by the subquery.

SQL> select * from employees where department_id in (select department_id from departments where location_id = 1700);

A similar exception that relates to returned number mismatch is ORA-00913: too many values. But they have different error patterns.

More comparison conditions like ANY, SOME or ALL should also be helpful to accept more than one row in your statements so as to avoid ORA-01427 in subquery statement.

2. Using = (Equal) Operator

If you really want to use an equal operator to confine the scope of returned rows as one, you have to limit the number of rows returned of queries to only one row. That’s how we workaround it.

SQL> select * from employees where department_id = (select * from (select department_id from departments where location_id = 1700) where rownum = 1);

An order by clause is more appropriate in the above subquery so as to be close to your expectation.

select * from employees where department_id = (select * from (select department_id from departments where location_id = 1700 order by manager_id) where rownum = 1);

3. Do Not Use DISTINCT with Equal Operator

Adding one distinct keyword before column list cannot prevent ORA-01427, because the number of rows returned by the subquery is still unpredictable.

SQL> select * from employees where department_id = (select distinct department_id from departments where location_id = 1700);
select * from employees where department_id = (select distinct department_id from departments where location_id = 1700)
                                               *
ERROR at line 1:
ORA-01427: single-row subquery returns more than one row

No surprises, we saw ORA-01427 in SELECT statement once again.

B. ORA-01427 in Job Failed by Trigger

Same error ORA-01427 could accompany ORA-12012 in the alert log when one scheduled job failed to complete successfully.

ORA-12012: error on auto execute of job 10
ORA-01427: single-row subquery returns more than one row
ORA-06512: at line 21

Trigger Caused ORA-01427

According to this error pattern in the above, we saw ORA-01427 in a failed job with ORA-12012. We’d better check some triggers, especially logon and logoff ones to see if there’s any chances to block the job process accidentally. Noticeably, which is Job No. 10 in this case.

You should check the content of the job in the first place to see if there’re any chances to throw ORA-01427. Perhaps you should disable each trigger at a time in order to isolate and identify the cause. Or just turn them off temporarily.

Further reading: How to Kill Session in Logon Trigger

C. MySQL Subquery Returns More Than 1 Row

The same error pattern occurs in MySQL, incorrect number of rows from subquery will result ERROR 1241, let’s see its content:

ERROR 1242 (ER_SUBSELECT_NO_1_ROW)
SQLSTATE = 21000
Message = «Subquery returns more than 1 row»

This error is caused by the subquery that must return at most one row but returns multiple rows eventually.

mysql> select * from items where id = (select item_id from orders);

If the subquery returns just one row, the above query will work without errors. If it returns more than one row, we will see error 1242.

The solution is the same as we mentioned in the above sections. Beside IN operator, we can also use ANY, one of comparison conditions to fix the query, for example:

mysql> select * from items where id = any (select item_id from orders);

This is how comparison conditions work for MySQL.

SELECT ...
  FROM mtl_material_transactions mmt
 WHERE ...

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

Но вот возникла необходимость добавить в запрос еще одну колонку — счет ГК с которого списали ТМЦ. Мы знаем, что в таблице mtl_transaction_accounts по коду складской транзакции можно найти две полупроводки, одна с положительной суммой (дебет), другая с отрицательной (кредит). Ну вот значит счет кредитовой полупроводки нас и интересует. Самым простым способом «вклиниться» в существующий запрос будет что-то такое:

SELECT ...
      ,(SELECT mta.reference_account
          FROM mtl_transaction_accounts mta
         WHERE mta.transaction_id = mmt.transaction_id
           AND mta.base_transaction_value < 0
       ) AS "Счет учета ТМЦ"
  FROM mtl_material_transactions mmt
 WHERE ...

Запускаем — беда!
ORA-01427: подзапрос одиночной строки возвращает более одной строки

Почему возникла ошибка?
Для некоторых складских транзакций наши предположения оказались неверны.
И это плохо.
А плохо потому, что проблемными могут оказаться всего лишь пара записей из нескольких тысяч, а мы не увидим ничего, т.к. весь запрос возвращает ошибку.

Прежде чем начинать исправить ситуацию, нужно понять а какой собственно результат запроса был бы приемлемым, учитывая наличие складских транзакций с неожиданными распределениями(проводками)?

А хотелось бы, чтобы запрос таки отработал, и все сотни, а то и тысячи (а то и больше) «правильных» записей мы увидели, а для тех нескольких ошибочных пусть вернется хоть что-нибудь — мы с ними отдельно разберемся, главное чтобы их отличить от правильных можно было.

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

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

SELECT ...
      ,(SELECT MAX(mta.reference_account)
          FROM mtl_transaction_accounts mta
         WHERE mta.transaction_id = mmt.transaction_id
           AND mta.base_transaction_value < 0
       ) AS "Счет учета ТМЦ"
  FROM mtl_material_transactions mmt
 WHERE ...

Однако. Как оказалось, вернуть что-нибудь — не проблема, проблема потом понять что получили. Применив групповую функцию MAX мы гарантируем, что ошибки ORA-01427 больше не будет. Какой-нибудь счет да вернется. Но при таком подходе, мы никогда и не узнаем, что у нас есть записи с некорректно
определенным счетом.

Тем не менее, главный шаг к правильному решению уже сделан, осталось чуть-чуть. Ведь во всех случаях, где подзапрос возвращает одну запись, использование MAX не является ошибкой — максисум от одного значения равен самому значению. Значит нам нужно в тех случаях, где подзапрос возвращает одну запись — использовать
MAX (ну хотите MIN). А там где больше чем одну — возвращать значение, указывающее на ошибку.

Так ведь это же совсем не сложно сделать!
Количество записей подзапроса — это COUNT(*), условную логику можно реализовать через CASE или, по старинке, через DECODE. Не забудем и про то, что подзапрос может совсем не вернуть записей:

  
SELECT ...
      ,(SELECT DECODE(COUNT(*),  1,MAX(mta.reference_account),  0,NULL,  -999)
          FROM mtl_transaction_accounts mta
         WHERE mta.transaction_id = mmt.transaction_id
           AND mta.base_transaction_value < 0
       ) AS "Счет учета ТМЦ"
  FROM mtl_material_transactions mmt
 WHERE ...

Всё.
Теперь не только ошибка ORA-01427 больше не появится, но и можно легко найти те записи, где наша логика определения счета учета ТМЦ дала сбой.

Дополнительно отметим, что так как mta.reference_account имеет числовой тип данных, то и ошибочное значение должно быть числовым (-999). Для строковых типов данных можно было бы использовать — ‘Ошибка’ или ‘ORA-01427’. Для дат — что-то из далекого прошлого или будущего. Важно лишь, чтобы такого значения гарантированно не было в реальных данных.

Подводим итоги.
При использовании подзапросов вместо

SELECT
       (SELECT t2.column
          FROM table2
         WHERE ...)
  FROM table1 t1
 WHERE ...

лучше использовать

SELECT
       (SELECT DECODE(COUNT(*), 0,NULL, 1,MAX(t2.column), 'ORA-01427')
          FROM table2
         WHERE ...)
  FROM table1 t1
 WHERE ...

И не забыть разобраться почему появились записи с ‘ORA-01427’