Нужно упростить запрос

← →
Ольга © (2009-07-08 14:30) [40]

> Тогда хуже, поскольку там может быть что угодно, включая
> пользовательские типы.

"Там" это где? Это "кривенькое" поле мы разобрали по косточкам, информация в нем однородная... Каких сюрпризов можно ждать?

← →
clickmaker © (2009-07-08 14:35) [41]

в запросе в [0] слишком много вызовов CHARINDEX.
Я бы курсором прошелся по таблице

← →
Ольга © (2009-07-08 14:52) [42]

Запрос в [0] и есть попытка создать курсор. "Табуретки" и "валенки" входят в состав естественного первичного ключа, которого реально в таблице нет. Вот я и хочу создать курсор, после чего N раз прогнать через него эту же таблицу, расфасовывая информацию в новую базу.

← →
Anatoly Podgoretsky © (2009-07-09 08:49) [43]

> "Там" это где? Это "кривенькое" поле мы разобрали по косточкам,
> информация в нем однородная... Каких сюрпризов можно ждать?
>

В sql_variant = можно хранить, что угодно, даже пользовательские типы.
И для разборки надо знать формат. Поддержка ложится на пользователя, а не на сервер.

← →
amir (2009-07-09 16:37) [44]

Попробую пожелиться некоторым опытом. На новой (уже старой :)) работе столкнулся с древним (ЕС-м) представлением чисел в базе в символьном виде. Т.е. есть таблица, в одном из полей которой "сидят" строки по 8 символов-цифр без всяких точек. В другом поле - 6 символов-цифр и т.д. Никакой документации нетути. Последний программист, который сто-то там помнил, уволился лет 5 назад. В качестве "отправной" точки имеются только всевозможные ведомости, в которых, как правило, результаты вычислений, а не сами "числа", причем, ессно, числа дробные.
Пока не залез в асмовские исходники и не посмотрел как там выделяется дробная часть при вычислениях (если кто помнит - десятичная упакованная арифметика), не смог разобраться.

ИМХО, это похоже на тот случай. Т.е. корректно разобраться где "валенки", а где "сапоги" без разбора программного кода невозможно.

Нужно упростить запрос Найти похожие ветки