Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Порядок обработки записей оператором UPDATE
|
|||
|---|---|---|---|
|
#18+
Можно-ли как то задать порядок обработки записей оператором UPDATE ? Например если есть 2 поля: mes & summa, нужно обрабатывать записи в порядке возрастания mes, т.к. summa в текущем месяце вычисляется в зависимости от суммы в предыдущем месяце ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2002, 08:23 |
|
||
|
Порядок обработки записей оператором UPDATE
|
|||
|---|---|---|---|
|
#18+
На "живой" таблице - порядок выполнения UPDATE по строкам совпадает с размещением данных в записях (т.е. - по кластерному индексу). Если нужен порядок выполнения отличный от кластерного индекса - можно сделать: SELECT ... INTO #temp_table FROM ... WHERE ... ORDER BY ... Во временной таблице - порядок выполнения UPDATE будет соответствовать порядку попадания туда записей, обусловленному предыдущим ORDER BY ... З.Ы. никаких ссылок на документацию по этому поводу - не имею, просто - неоднократно проверенный и используемый многими опыт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2002, 08:47 |
|
||
|
Порядок обработки записей оператором UPDATE
|
|||
|---|---|---|---|
|
#18+
2 qu-qu и др. "курсороненавистникам" A не было ли случаев когда порядок выполнения update во временной таблице для 7.0 и выше не соответствовал бы выше приведенному утверждению qu-qu? Что будет если временная таблица будет ну о-о-очень большой? Вопрос не праздный. Давно хочу засунуть курсоры куда подальше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2002, 11:03 |
|
||
|
Порядок обработки записей оператором UPDATE
|
|||
|---|---|---|---|
|
#18+
Прямо по озвученному вопросу ничего конкретно сказать не могу. Однако, я столкнулся с интересным поведением оператора UPDATE в случае, когда используется синтаксис с двойным FROM, а конструкция после второго FROM возвращает число записей больше , чем в модифицируемой таблице. Мне было необходимо не просто проапдейтить записи, но еще и запустить триггер, в котором должны были обработаться несколько вариантов модификации одной записи. То есть, выполнить модификацию каждой записи не однократно, а многократно. К сожалению, отрабатывает только опервый попавшийся в выборке вариант модификации записи. Хотел дать ссылку на свое сообщение на форуме, искал все комбинации фразы "чертов однопроходный update", но почему-то найти не смог. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2002, 17:48 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32026210&tid=1823367]: |
0ms |
get settings: |
6ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
52ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 228ms |
| total: | 355ms |

| 0 / 0 |
