обновление поля, входящего в уник. ключ

[_A_]

Может это уже всплывало тут.
Импортом из экселя загоняется таблица RContractTable, далее запускается нижеследующий код, с целью инициализации RContractAccount из нужной номерной серии. Проблема в том что цикл уходит в нирвану и в наборе уже появляются обновленные записи с новым RContractAccount и так до бесконечности. Обновление через еще одну табл. переменную не проходит. Я понимаю что может проблема решится путем написания кода инициализации при импорте, но все хотелось бы пгонять в чем тут дело, может здесь что-то очевидное. Заранее спасибо

static void updateContractCode(Args _args)
{
     RContractTypes      rContractTypes;
     NumberSeq           numberSeq;
     RContractTable      rContractTable;
     ;
     ttsbegin;
     while select forupdate rContractTable
     {
            rContractTypes = RContractTypes::find(rContractTable.RContractPartnerType,
                                                              rContractTable.RContractCode);
     if (rContractTypes.NumberSequenceCode)
      {
               numberSeq    = NumberSeq::newGetNumFromCode(rContractTypes.NumberSequenceCode,true);
            rContractTable.RContractAccount = numberSeq.num();
            rContractTable.update();

          }
     }
     ttscommit;
}

[Vadik]

происходит то же, что и всегда - MSSQL, динамический курсор, доступ по некластерному индексу

см. while select зацикливается на одной записи

в качестве одного из вариантов решений - добавляйте
..
where RContractAccount != ""

либо создайте кластерный индекс
либо инициализируйте код сразу при импорте
и т.д.

[_A_]

Все понятно, спасибо!
З.Ы.

Цитата:

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

либо создайте кластерный индекс

Кстати говоря он там был и есть

[KiselevSA]

Если уникальный ключ основан на номерной серии, то оптимальным способом "закачки" или обновления данных в таблице будет следующий:
- отключите запрет уникальности по полю с индексом на основе номерной серии
- закачайте данные
- обновите поле с помощью Job на основе номерной серии
- включите запрет дублирования, синхронизируйте таблицу

[_A_]

Всё это делалось - результат аналогичный.

Вобщем на мой взгляд проще при импорте инициализировать, ну а чтобы совсем не париться и забыть, предварительно сосчитать количество записей в таблице, а потом используя счетчик в конце концов сделать break

[Vadik]

Цитата:

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

Кстати говоря он там был и есть

Таки да, есть, проглядел. Значит, не используется. Стало быть, либо навязать его хинтом (некрасиво), либо доп. условие (RContractAccount != '')
Или импорт через группу определений с типом "произвольный" (инициализацию полей можно делать перед сохранением записи)
Счетчики и break - imho от лукавого: где гарантии, что одни записи не обработаются вдважды-трижды, а другие - ни разу?

[_A_]

Цитата:

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

либо доп. условие (RContractAccount != '')

пробовал, результат тот же

Цитата:

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

Или импорт через группу определений с типом "произвольный" (инициализацию полей можно делать перед сохранением записи)

и я о том же

Цитата:

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

Счетчики и break - imho от лукавого: где гарантии, что одни записи не обработаются вдважды-трижды, а другие - ни разу?

согласен, от лукавого Но в конце концов и это обойти можно, сортировку например включить по дате-времени обновления, если таковые поля имеются