"Двойное" обновление строк

[Xardas]

Добрый день, знатоки. В процессе отладки программы столкнулся со странностью.

    ttsbegin;

    i = 1;
    while select forupdate inOutData
          where inOutData.InOutDate >= firstDate &&
                inOutData.InOutDate <= lastDate
    {
        if (i <= conlen(data))
        {
            con = conpeek(data, i);
            inOutData.EmplId    = conpeek(con, 1);
            inOutData.InOutDate = conpeek(con, 2);
            inOutData.InOutTime = conpeek(con, 3);
            inOutData.InOutType = conpeek(con, 4);
            inOutData.update();
        }
        else
            inOutData.delete();
        i++;
    }

    while (i <= conlen(data))
    {
        con = conpeek(data, i);
        inOutData.clear();
        inOutData.EmplId    = conpeek(con, 1);
        inOutData.InOutDate = conpeek(con, 2);
        inOutData.InOutTime = conpeek(con, 3);
        inOutData.InOutType = conpeek(con, 4);
        inOutData.insert();
        i++;
    }

    ttscommit;

В данном коде некоторые строки в цикле while select forupdate обновляются... дважды. И, соответственно, часть из них переписывается. Стоит только добавить в запрос строку order by RecId, и алгоритм начинает работать как часы. Контейнер data был одинаков для обоих прогонов. С чем может быть связано такое странное поведение?

[ice]

скорее всего из-за того что вы меняете значения полей, которые участвуют в фильтре селекта

[Xardas]

ice, да, они могут поменяться, но по прежнему остаются в диапазоне firstDate .. lastDate. И каким образом добавление сортировки решает проблему?

[Fanygrom]

Сталкивался с подобными ситуациями на разных версиях MS SQL. При обновлении полей участвующий в критериях запроса, происходит повторная выборка. Видимо при сортировки этого не происходит.

[Владимир Максимов]

Цитата:

Сообщение от Xardas

ice, да, они могут поменяться, но по прежнему остаются в диапазоне firstDate .. lastDate. И каким образом добавление сортировки решает проблему?

Если сортировка не указана явно, то, по умолчанию, упорядочивание идет по кластерному индексу (если это возможно). У Вас поле InOutDate в кластерном индексе таблицы inOutData не используется?

[Xardas]

Владимир Максимов, на этой таблице вообще нет кластерного индекса.

[Владимир Максимов]

Несколько аксиом SQL-серверов

• В общем случае, при отсутствии опции ORDER BY, порядок следования записей в выборке случаен и не предсказуем (наличие кластерного индекса не дает гарантий)
• Изменение данных в таблице может приводить как к логическому, так и к физическому изменению положения записи в таблице. В общем случае, перемещение также будет случайно и не предсказуемо.

Из этого следует, что при отсутствии опции ORDER BY модификация данных в цикле может приводить к многократным повторным модификациям. Можно считать это фичей работы с SQL-серверами.

[Xardas]

Владимир Максимов, хорошо, с этим понятно. А что произойдет, если я сделаю сортировку по неуникальному полю? Например, EmplId в данной таблице неуникально. Порядок строк с одинаковым EmplId также будет случаен?

[Владимир Максимов]

Цитата:

Сообщение от Xardas

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

В общем случае, да. Случаен.

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

order by EmplId, RecId

Для общего развития можете посмотреть статьи на sql.ru

Вопрос на злобу дня - Просмотр кластеризованного индекса - Часть I
Вопрос на злобу дня - Просмотр кластеризованного индекса - Часть II
Вопрос на злобу дня - Просмотр кластеризованного индекса - Часть III

Где очень кратко рассматривается внутренняя механика выборки MS SQL 2000 и 2005 в случае наличия кластерного индекса

Вот здесь чуть побольше и разнообразнее

Индексы. Теоретические основы

[Xardas]

Владимир Максимов, благодарю развернутые ответы!