Страница 1 из 1
The cursor identified in the update or delete statement is n
Добавлено: 04 окт 2007, 13:15
entryway
Сегодня ни с того ни с сего перестал работать запрос с ошибкой описанной тут:
http://tracker.firebirdsql.org/browse/CORE-897
Код: Выделить всё
The cursor identified in the update or delete statement is not positioned on a row.
no current record for fetch operation
фаирберд 1.5.4.4910
выборка такая
Код: Выделить всё
select
...
smpp_services.name,
from smppsms s
...
inner join smpp_services on smpp_services.id = s.service_id
В справочнике smpp_services 4 записи с ID 1,2,3,4
В smppsms ссылоки есть только на 2 с ID 1 и 2.
После замены иннера на лефт - запрос выполняется. Странно.
В справочнике smpp_services обнаружил левое значение по ID=4 в поле name (Ђ). Удалить\заменить его не помогает.
Пробовать запускать гфикс, бакап и рестор?
Добавлено: 04 окт 2007, 14:19
entryway
бакап\рестор проблему не решил
Добавлено: 04 окт 2007, 14:20
Dimitry Sibiryakov
Дай протелепаю: в запросе используется процедура?
Добавлено: 04 окт 2007, 14:27
entryway
Вообще-то этот запрос вызывается из процедуры (больше в процедуре ничего нет). При выполнении процедуры случайным образом возвращаются то ноль записей, то много и неправильных (должно быть 3 записи). Поэтому и заметили.
При попытки исполнении запроса вне процедуры - всегда возвращается описанная мною ошибка. Пересоздание справочника smpp_services (smpp_services2) и изменения запроса не решило проблемы. Помогает как воркэраунд только замена иннера на лефт. Коду этому - год. Проблема возникла именно сегодня. Думаю это связано с появившимся левым значением в справчнике, но как я уже говорил, пересоздание справочника не помогает. Бакап рестор тоже. Ошибок - нет.
Re: The cursor identified in the update or delete statement
Добавлено: 04 окт 2007, 14:30
WildSery
entryway писал(а):выборка такая
В выборке только две таблицы джойнятся, и больше ничего?
Добавлено: 04 окт 2007, 14:30
entryway
Хотя я наверное ошибаюсь в детекте проблемы
Вот полный код запроса
Код: Выделить всё
select
s.id,
s.service_id,
smpp_services.name,
sms_states.name,
s.date_request,
s.phone,
s.question,
s.answer,
o1.operator,
o2.operator,
0,
s.lastupdate
from
smppsms s
left join operators o1 on o1.id = s.operator_id
left join operators o2 on o2.id = s.assigned_operator_id
inner join sms_states on sms_states.id = s.state
inner join smpp_services on smpp_services.id = s.service_id
where (sms_states.doshow = 1)
order by s.date_request desc
комментирование
-- o1.operator,
-- o2.operator,
и
-- left join operators o1 on o1.id = s.operator_id
-- left join operators o2 on o2.id = s.assigned_operator_id
тоже помогает, а по отдельности - нет
Такое:
-- sms_states.name,
-- inner join sms_states on sms_states.id = s.state
-- where (sms_states.doshow = 1)
тоже отработает на ура
Добавлено: 04 окт 2007, 14:38
entryway
Трындец. Помогает просто поменять местами жоины.
Код: Выделить всё
inner join sms_states on sms_states.id = s.state
inner join smpp_services on smpp_services.id = s.service_id
left join operators o1 on o1.id = s.operator_id
left join operators o2 on o2.id = s.assigned_operator_id
Работает. Это нормально такое поведение? :)
Как то в жизни складывается так, что 90% проблем с фаирбердом решается изменением порядка жоинов...
Добавлено: 04 окт 2007, 15:00
entryway
Создал отдельную базу с 4мя таблицами участвующими в запросе. Описанный выше селект на ней тоже не работает. При изменении порядка жоинов - работает.
http://prboom-plus.sourceforge.net/fb_test.zip
FB 1.5.4.4910
Вот минимальный запрос, который возвращает ошибку с первого поста:
Код: Выделить всё
select * from smppsms s
left join operators o1 on o1.id = s.operator_id
inner join sms_states on sms_states.id = s.state
inner join smpp_services on smpp_services.id = s.service_id
Поведение процедуры которая делает выборку с поста выше - вообще смешное.
Добавлено: 04 окт 2007, 15:08
Slavik
Я давно уже заметил, что в FB left join'ы лучше ставить после inner join'ов. С тех пор, как взял себе это за правило, подобных проблем нет. Оно и логично -- сначала обязательные условия, потом - необязательные.
Добавлено: 04 окт 2007, 15:10
entryway
Slavik писал(а):Я давно уже заметил, что в FB left join'ы лучше ставить после inner join'ов. С тех пор, как взял себе это за правило, подобных проблем нет. Оно и логично -- сначала обязательные условия, потом - необязательные.
Иногда загадочным образом запросы с лефтжоинами которые стоят после иннеров выполняются в 1000 раз медленнее чем наоборот. Ну да это к проблеме отношения не имеет.
Добавлено: 04 окт 2007, 16:05
Tonal
А что, планы запросов нонича не кошерно смотреть?
Добавлено: 04 окт 2007, 16:09
kdv
в дополнение - ставьте везде алиасы таблиц. А то не запрос, а безобразие какое то.
s.service_id,
smpp_services.name,
sms_states.name,
s.date_request,
left join operators o2 on o2.id = s.assigned_operator_id
inner join sms_states on sms_states.id = s.state
inner join smpp_services
так трудно указать алиасы для ВСЕХ таблиц?
p.s. еще тему из "ремонта БД" перенес.
Добавлено: 04 окт 2007, 16:10
entryway
Tonal писал(а):А что, планы запросов нонича не кошерно смотреть?
Лишь бы что-то сказать? Перечитай первый пост - проблема описана там.
kdv писал(а):в дополнение - ставьте везде алиасы таблиц. А то не запрос, а безобразие какое то.
так трудно указать алиасы для ВСЕХ таблиц?
Спасибо, но это, увы, не имеет отношения к проблеме.
Добавлено: 04 окт 2007, 16:11
kdv
Лишь бы что-то сказать?
как раз в таких случаях, особенно если "медленно" или "неправильно работает", и надо указывать планы.
Добавлено: 04 окт 2007, 16:17
entryway
kdv писал(а):как раз в таких случаях, особенно если "медленно" или "неправильно работает", и надо указывать планы.
Да при чем тут "медленно" и "неправильно", пацаны? Что вы уже за уши притягиваете что попало. Я выложил необходимые и досточные данные для воспроизведения проблемы, а "просто поговорить" на отвлеченные темы оптимизации и стиля у меня желания в этом топике нет. Как план поможет избавится от "The cursor identified in the update or delete statement is not positioned on a row. no current record for fetch operation"? Можно не отвечать на этот вопрос.
Попросил проверить товарища в 2.х фаирберде. Работает там.
Добавлено: 04 окт 2007, 17:05
kdv
Что вы уже за уши притягиваете что попало.
не надо буянить. я тебе дал дельный совет, за который ты мне скажешь спасибо, если будешь переходить на FB 2. Там к указанию алиасов сервер более жестко относится.
p.s. на 1.5.3 проблему проверял?