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

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

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

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

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

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

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

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