особенности типов данных?

Добрый день!

1) можно ли расценивать выполнение этого кода на SQL8SP3, как плохо вычищенную процедуру от старой версии?

exec sp_addtype 'TLU2', 'sysname', 'not null'
exec sp_addtype 'TLU2', 'sysname(1)', 'not null'

2) не появился ли какой _недокументированный_ способ писать udt в convert?

3) считать ли особенностью или ошибкой sp_columns(или ещё какой-то), что при наследовании типа колонки при select into #, она их пропускает, если конечно такой тип не создан в tempdb руками

1. sysname is a system-supplied user-defined data type that is functionally equivalent to nvarchar(128) and is used to reference database object names. Зачем его переопределять и тем более урезать по длине? Пишите тогда уж nvarchar(1), не усложняйте код. Обратите внимание на вторую часть цитаты. Использование данного типа подразумевает определенную семантику. Поле (или переменная) такого типа означает имя объекта базы данных. Использовать его для других целей правильно синтаксически, но не логически.

2. CAST and CONVERT: User-defined data types cannot be used. Про _недокументированные_ способы, звиняйте, ничего сказать не могу.

3. Совершенно нормальное поведение. При получении информации о типах данных используется запрос из systypes, которая существует в каждой базе. В своей пользовательской базе вы создали новый тип, да. Но в tempdb его нет. Откуда же ему взяться в результатах выполнения sp_columns? Правильно, если его создадите и в tempdb тоже, то sp_columns начнет его выдавать.

1) при выполнении указанного кода возникают ошибки
The data type 'sysname' does not exist.
You cannot specify a length for user data types based on sysname.
это говорит о том, что с одной стороны типа не существует, а с другой стороны существуют особенности работы с ним. Вопрос относится к процедуре, а не к типу.
2) если sysname is a system-supplied user-defined data type и в него можно делать convert, то нельзя ли и моим типам прикинуться system-supplied каким-нибудь образом?
3) Если При получении информации о типах данных используется запрос из systypes, которая существует в каждой базе, то почему select into # переносит несуществующие типы? Получается, что одна часть системы слабо совместима с другой. Если виновата sp_columns, то это ерунда, а если select into #, то как?