Добрый день!
Подскажите, пожалуйста, никто не сталкивался ли со следующим багом:
Есть таблица с остатками(Oracle 11.2) : дата, счет,входящий остаток, исходящий остаток.
Мне нужно получить остатки только по нескольким тысячам счетов из нескольких миллионов.
Я написал в PreparedStatement запрос вида
select дата, счет,входящий остаток, исходящий остаток from таблица_остатков
where счет in (?,?,?,?,?)

Входящих параметров(?) в in одна тысяча.
Я их инициализирую в цикле и получается, что для одного счета возвращаются значения из остатков другого счета.
Причем если доабвить что-нибудь типа
where счет in (?,?,?,?,?) order by дата desc, то все ок.
Если
where счет in (?,?,?,?,?) order by дата asc, то баг повторяется.

Локшин Марк,
Код рабочий, чтобы его опубликовать нужно "обезлчивать".
Всю суть проблемы я описал в схематическом виде.

Usman,
Это я пробовал. Принципиально ничего не меняется.

Alexey TominNordallЛокшин Марк,
Код рабочий, чтобы его опубликовать нужно "обезлчивать".
Всю суть проблемы я описал в схематическом виде.

В схематическом виде опубликовано ВАШЕ ПЕДСТАВЛЕНИЕ, что баг есть.
Либо ошибка в коде, либо в базе данных. Какая она, кстати?

Что ошибка в походе- это понятно и так- 1000 параметров это эталонный говнокод.

Базу я указал - Oracle 11.2.0.4

Значение 1000 - это лимит для количества значений в in.

Если есть 3000 счетов и нужно по ним получить значения из нескольких миллионов записей,
то что будет быстрее - обработать в Java результат трех запросов к базе
или 3000 тысячи раз выполнять запрос по одному счету.
Первый вариант работает быстрее, значит это говнокод?
Инициализируются 1000 параметров естественно в цикле.

Сергей АрсеньевUsmanNordall
У чела другая проблема. Он не ищет путь к динамике. Его устраивает тыща параметров.
Просто он полагает, что PreparedStatement виновато, что если попросить данные по счетам перечислив их через запятую, то в результате будут данные по всем перечисленным счетам.

А вовсе не из-за очередного бага СУБД на тему при большом количестве строк представление завернутое в другое представление начинает возвращать что-то от балды.

Запрос из prepared statement c явно перечисленными значениями, выполненный в sql plus,возвращает все корректно.

Alexey TominNordallЕсли есть 3000 счетов и нужно по ним получить значения из нескольких миллионов записей,
то что будет быстрее - обработать в Java результат трех запросов к базе


Ьыстрее вставить данные во временную (реально временную, или специальную по ключу сессии) таблицу 3000 ID счетов и выполнить inner join


На боевой системе создавать временную таблицу нереальное решение.

вадяNordall,
по твоему вопросу видно, что ты не владеешь знаниям по субд, номера счетов повторяются кажый год, но количество счетов разно каждый год. вот от этого у тебя баг
Причем тут знания субд и счета???
Счета повторяются и что?
Я делаю select из таблицы балансов.
В ней номер счета всегда уникален за дату.

Alexey TominNordallНа боевой системе создавать временную таблицу нереальное решение.

Не вижу проблемы. Много раз использовал в oracle как настоящие временные таблицы, так и таблицы с ключём по sessionId (для передачи данных между сессиями). Объёмы были- большие.
А вот использование вместо этого тысяч параметров in - это то, за что надо увольнять сразу.
Я не хочу вступать в обсуждение с вами, что есть говнокод и за что уволнять или нет. Для этого есть ПТ.
Сделано это для максимальной производительности. Можете возразить, что это работает медленее?
У всех разные проекты и опыт.
Очень рад, что вам разрешают создавать временные таблицы на продуктивном сервере с десятками проектами пользующимися данными по остаткам.