Home/ Questions/Q 6004029
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T01:12:19+00:00

I have the following Execution statement which creates a table (using data from another

  • 0

I have the following Execution statement which creates a table (using data from another procedure), inserts the values into a temporary table, adds an image column (because they cannot be included in the grouping), and then updates it based on criteria from another temporary table (the resulting table fields gets used in a SSRS report, so I need to retain the IMAGE data type):

EXEC ('SELECT ' + @COL_TO_GROUP_BY + @COL_ADDITONAL + @sColVals + ' INTO
#RESULTS_TABLE from (' + @SQL_STATEMENT + ') A ' + @WHERE_CLAUSE + ' GROUP BY ' +
@COL_TO_GROUP_BY +

' ALTER TABLE #RESULTS_TABLE
ADD IMAGE_DATA IMAGE

IF EXISTS(SELECT * FROM tempdb.INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME = 
''COLUMN_A'' and TABLE_NAME LIKE ''#RESULTS_TABLE%'')
BEGIN
    UPDATE #RESULTS_TABLE
    SET IMAGE_DATA = FILE_DATA
    FROM #RESULTS_TABLE A, #IMAGE_TABLE B 
    WHERE A.COLUMN_A = B.COLUMN_A
END

SELECT * FROM #RESULTS_TABLE')

The problem is that regardless of whether COLUMN_A exists or not, the column for IMAGE_DATA is always NULL. Is there any other way to get data into the IMAGE_DATA column? Please help!

Note: I will not be accepting any answers that conclude that the problem is related to the content in other tables, more specifically from the WHERE clause. I have done multiple validations to ensure the conditions can be both true and false (matching rows, no matching rows, etc..). So this rules out the conditional statement. Thanks.

EDIT:

I’m still not completely sure what the exact cause of it was, but I ended up creating a global temporary table and ran two separate procedures, now it seems to be working fine. I had to accept the answer that most closely matched my own solution. All answers and comments were very viable. Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Correct.

    At the time of compilation, the column doesn’t exist. That is, SQL Server looks at the whole set of commands and parses/compiles it. The effects of an ALTER TABLE in the code won’t be visible to later commands.

    You have to do the ALTER TABLE separately to the UPDATE

    Note: For SQL Server 2005 you’d have varbinary(max) which is far more flexible and remove some complexity

    • 0