Да, будет заново компилировать. Что Вас так удивляет? План запроса никогда не будет шариться при различии параметров настройки сред окружения пользовательских сессий, могущих повлиять на ход выполнения запроса. Возьмите какой-нибудь select * from authors и выполните его с 2-х сессий. (Только сначала сделайте DBCC FREEPROCCACHE). В одной перед запросом поставьте set ansi_warnings on, в другой off. А теперь посмотрите select sql, db_name(dbid) from master..syscacheobjects where cacheobjtype = 'Executable Plan' and objtype = 'Prepared', сколько планов получилось. Про это, по-моему, даже в документации сказано. А если не сказано, то все равно здравый смысл должен подсказать. Жизнь наша с вами так устроена, что чудес не бывает. Либо компилировать план вместе с частью среды окружения (ситуация, типичная для хранимых процедур и обычных представлений), либо в предположении, что все они заведомо фиксированы, сиречь, кругом царит сплошной детерминизьм (ситуация хранимых функций и "материалистических" представлений). Кстати, по поводу первой ситуации меня достаточно давно, еще во времена 7.0, один пионэр с ВМК спрашивал, что, мол, как же так, ведь у вас декларирована реентерабельность планов? Но никто и не утверждал, что в памяти хранятся два одинаковых куска кода с разными стеками. Просто здесь такая ситуация, что содержимое стека в действительности влияет на сам код.

Уважаемый Василий.
Дела обстоят именно так, а нормально это или нет - к сожалению, личностные оценки, во многом продиктованные привычкой. Я думаю, что нормально, когда end users не запускают EM, а работают с сервером через Вами написанный интерфейс, где учтены подобные нюансы. Несмотря на свою продвинутость, SQL Server - всего лишь программа, которая на данной стадии не способна бегать за Вас за пивом в силу присущих ей объективных ограничений, суть которых, как мне казалось, я объяснил.
По поводу учебников - по-моему, Вы чего-то недопоняли. Когда от клиента поступает запрос, то SQL Server, естественно, прежде, чем бросаться его выполнять, поищет его план в процедурном кэше на предмет не посылал ли клиент его уже незадолго перед этим. Так что с этой точки зрения я, честно говоря, вижу мало разницы между размещением бизнес-логики на сервере и на клиенте. Серверный вариант предпочтителен с точки зрения централизации и управляемости. Напр., с выходом SQL Srv 2000 многие стали держать маски ввода полей и прочие правила форматирования в extended properties. Чтобы клиентская прилада их оттуда считывала и сама ничего не придумывала. К сожалению, иногда это невозможно. На форуме уже обсуждался вопрос, как отлавливать на клиенте изменения в записи. Сейчас это невозможно, поэтому приходится изобретать компоненту промежуточного слоя и все updates гнать через нее. Но как только в след.версии SQL Server научится генерить пользовательские events, чест.слово, я снесу эту dll и вставлю все в триггер.