Я работаю с древовидными структурами. Идентификаторы записей имеют тип uniqueidentifier. Для того, чтобы можно было во VIEW без существенных тормозов выбрать поддерево записей, заданное ID записи-вершины поддерева, я во вспомогательном столбе у каждой записи сохраняю путь к этой записи от корня дерева. Путь сохраняется в поле varbinary(360). В него укладываются по порядку идентификаторы записей, начиная от корня дерева с преобразованием cast(UniqueidentifierVar as varbinary(16)), которые сцепляются конкатенацией.
Для того, чтобы отобрать поддерево, вершину которого образует запись с заданным ID, я использовал такую конструкцию:
... where TopRecord.Path+cast(TopRecord.ID as varbinary(16))=Substring(AllRecords.Path,1, Len(TopRecord.Path)+16))
Подобная конструкция работает, но, как выяснилось, не во всех случаях. После тщательных разборок выяснилось, что Len(Path), которая обязана возвращать значения кратные 16, возвращает их иногда на единичку меньше. Происходит это тогда, когда поле Varbinary заканчивается нулевым байтом. Самое интересное, что конкатенация работает корректно (хвостовой нулевой байт не пропадает, если к "строке" varbinary прицепить еще что-нибудь).
Выкрутиться я выкрутился. Слава богу, есть еще одно поле - номер уровня в дереве:
... where TopRecord.Path+cast(TopRecord.ID as varbinary(16))=Substring(AllRecords.Path,1, (TopRecord.[Level]+1)*16)
Но замысловатое поведение функции Len() взял на заметку.
И заметку эту постирую на форуме - может, кому-то еще пригодится.

Адександру Гладченок спасибо за ссылочку. Ранее я ее проворонил.
И небольшая поправочка. Некорректная длина строки varbinary возвращается при хвостовых байтах, содержащих не нули, а код 20 шестнадцатиричное (то есть код пробела).

datalength() - то что надо! Спасибо.