Недопустимое имя столбца...

demoniqus
Дата: 12.05.2015 11:16:00
Есть две процедуры
ALTER PROCEDURE [dbo].[calcForm]
AS
BEGIN
IF OBJECT_ID(@tmpDBPrefix + '#tNL') IS NOT NULL
		DROP TABLE #tNL;
SELECT * INTO #tNL FROM [tNodesLeft];
EXEC [dbo].[extendFNodesLists];
END

и
ALTER PROCEDURE [dbo].[extendFNodesLists]
AS
BEGIN
ALTER TABLE #tNL ADD [IdTable] BIGINT NULL;
UPDATE #tNL
		SET [IdTable] = ISNULL(tTabs.[IdTable], @IdTable)
		FROM #tNL
			LEFT JOIN [DbFmbaMainStructSbo].[dbo].[tTabs] AS tTabs ON tTabs.[IdForm] = #tNL.[lIdForm] AND tTabs.[CodeT] = ISNULL(#tNL.[lCodeT], @CodeT)
	WHERE #tNL.[lNodeType] = 1
END

По непонятной причине, если я добавляю колонку IdTable внутри процедуры extendFNodesList, то при обновлении этой колонки в процедуре extendFNodesList получаю сообщение о недопустимом имени столбца. Если же столбец создавать непосредственно внутри главной процедуры calcForm, то при обновлении всё нормально. При этом у меня есть другие временные таблицы, создаваемые в главной процедуре и модифицируемые во вспомогательных. Там никаких проблем с этим не было... Кто-нибудь может сказать, в чем может быть проблема?
Glory
Дата: 12.05.2015 11:17:58
demoniqus
Кто-нибудь может сказать, в чем может быть проблема?

У сервера нет проблемы. Он поступает так, как документировано.
demoniqus
Дата: 12.05.2015 11:23:26
А я и не говорю, что сервер виноват. Но с его пустыми сообщениями невозможно понять, по какой такой причине данное наименование недопустимо... И почему, если во вспомогательной процедуре закомментить команду обновления и вместо нее поставить select * from #tNL, то я вижу, что столбец на самом деле добавлен удачно?..
Glory
Дата: 12.05.2015 11:25:11
demoniqus
Но с его пустыми сообщениями невозможно понять, по какой такой причине данное наименование недопустимо..

По причине того, что это _документировано_
Нельяз в одном пакете менять структуру таблицы и обращаться к измененным полям
demoniqus
Дата: 12.05.2015 11:34:13
Тогда почему я могу собрать два текстовых запроса: один создает в таблице дополнительные колонки, второй выполняет подстановку данных в эти столбцы из другой таблицы через UPDATE - и выполнить эти запросы в одном пакете друг за другом через EXEC?
Glory
Дата: 12.05.2015 11:35:17
demoniqus
Тогда почему я могу собрать два текстовых запроса: один создает в таблице дополнительные колонки, второй выполняет подстановку данных в эти столбцы из другой таблицы через UPDATE - и выполнить эти запросы в одном пакете друг за другом через EXEC?

Потому, что вы еще не знаете и что такое пакет/batch в MSSQL
alexeyvg
Дата: 12.05.2015 11:37:35
demoniqus
Тогда почему я могу собрать два текстовых запроса: один создает в таблице дополнительные колонки, второй выполняет подстановку данных в эти столбцы из другой таблицы через UPDATE - и выполнить эти запросы в одном пакете друг за другом через EXEC?
Потому что это 2 разных пакета. Всё, что выполняется в EXEC() - отдельный пакет. Сервер пакет берёт, компилирует, и выполняет. Ошибки нет, в момент компиляции все колонки присутствуют.

А процедуру вашу сервер берёт, компилирует - опа, а колонки нету. Ошибка. Нормальная, совсем не "пустая".
demoniqus
Дата: 12.05.2015 11:52:41
Да я вообще не по части MS SQL... но дали задание и лишь один возможный исход - "Выполнить, нельзя не выполнить"...
Хм... вся эта муть с компиляцией пакетов звучит хреново - как это сначала все компилируют, не проверив, есть ли какие-то изменения?..
Ладно, спасибо за разъяснение... пошел делать еще кучу процедур...
Glory
Дата: 12.05.2015 11:58:27
demoniqus
Хм... вся эта муть с компиляцией пакетов звучит хреново - как это сначала все компилируют, не проверив, есть ли какие-то изменения?..

Вот так представьте себе. Потому что запрос - это не готовый exe файл с машинными кодами.

demoniqus
Ладно, спасибо за разъяснение... пошел делать еще кучу процедур...

Вы ерундой занимаетесь. Таблицы сразу должны создаваться нужного формата.
А вы по всей видимости создаете очередной универсальный велосипед
demoniqus
Дата: 12.05.2015 12:11:09
А вот тут уже вы, Glory, не имеете понятия о том, что говорите. Не всегда можно заранее предсказать структуру таблицы (в более общем случае структуру данных, требуемый функционал и т.д.). И универсальный велосипед гораздо лучше ежемесячной глобальной переделки огромных алгоритмов с жуткой логикой (из-за заказчика, у которого постоянно все полностью или частично меняется). Без обид. Мне на моем веку уже хватило подобных переделок...
За разъяснения благодарю... я все же не по части баз данных и вряд ли бы додумался до такого объяснения данной проблемы. На мой взгляд подобный подход как-то нарушает принцип последовательного выполнения команд... я, глядя на такую процедуру, был уверен, что сначала сервер во временную таблицу добавит новую колонку, а потом уже будет ее там искать, чтобы обновить, а никак не наоборот: сначала поискать, потом матюкнуться на разработчика... и со спокойной совестью завернуть выполнение...
По крайней мере для этого случая есть простое решение...))))