The cursor identified in the update or delete statement is n

[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 (Ђ). Удалить\заменить его не помогает.

Пробовать запускать гфикс, бакап и рестор?

[entryway]

бакап\рестор проблему не решил

[Dimitry Sibiryakov]

Дай протелепаю: в запросе используется процедура?

[entryway]

Вообще-то этот запрос вызывается из процедуры (больше в процедуре ничего нет). При выполнении процедуры случайным образом возвращаются то ноль записей, то много и неправильных (должно быть 3 записи). Поэтому и заметили.

При попытки исполнении запроса вне процедуры - всегда возвращается описанная мною ошибка. Пересоздание справочника smpp_services (smpp_services2) и изменения запроса не решило проблемы. Помогает как воркэраунд только замена иннера на лефт. Коду этому - год. Проблема возникла именно сегодня. Думаю это связано с появившимся левым значением в справчнике, но как я уже говорил, пересоздание справочника не помогает. Бакап рестор тоже. Ошибок - нет.

[WildSery]

выборка такая

В выборке только две таблицы джойнятся, и больше ничего?

[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)
тоже отработает на ура

[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% проблем с фаирбердом решается изменением порядка жоинов...

[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

Поведение процедуры которая делает выборку с поста выше - вообще смешное.

[Slavik]

Я давно уже заметил, что в FB left join'ы лучше ставить после inner join'ов. С тех пор, как взял себе это за правило, подобных проблем нет. Оно и логично -- сначала обязательные условия, потом - необязательные.

[entryway]

Я давно уже заметил, что в FB left join'ы лучше ставить после inner join'ов. С тех пор, как взял себе это за правило, подобных проблем нет. Оно и логично -- сначала обязательные условия, потом - необязательные.

Иногда загадочным образом запросы с лефтжоинами которые стоят после иннеров выполняются в 1000 раз медленнее чем наоборот. Ну да это к проблеме отношения не имеет.

[Tonal]

А что, планы запросов нонича не кошерно смотреть?

[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. еще тему из "ремонта БД" перенес.

[entryway]

А что, планы запросов нонича не кошерно смотреть?

Лишь бы что-то сказать? Перечитай первый пост - проблема описана там.

в дополнение - ставьте везде алиасы таблиц. А то не запрос, а безобразие какое то.
так трудно указать алиасы для ВСЕХ таблиц?

Спасибо, но это, увы, не имеет отношения к проблеме.

[kdv]

Лишь бы что-то сказать?

как раз в таких случаях, особенно если "медленно" или "неправильно работает", и надо указывать планы.

[entryway]

как раз в таких случаях, особенно если "медленно" или "неправильно работает", и надо указывать планы.

Да при чем тут "медленно" и "неправильно", пацаны? Что вы уже за уши притягиваете что попало. Я выложил необходимые и досточные данные для воспроизведения проблемы, а "просто поговорить" на отвлеченные темы оптимизации и стиля у меня желания в этом топике нет. Как план поможет избавится от "The cursor identified in the update or delete statement is not positioned on a row. no current record for fetch operation"? Можно не отвечать на этот вопрос.

Попросил проверить товарища в 2.х фаирберде. Работает там.

[kdv]

Что вы уже за уши притягиваете что попало.

не надо буянить. я тебе дал дельный совет, за который ты мне скажешь спасибо, если будешь переходить на FB 2. Там к указанию алиасов сервер более жестко относится.

p.s. на 1.5.3 проблему проверял?