The
creates the stored procedure without errors, but when the stored procedure is executed, the following error is reported
This is because when a stored procedure is created, it does a grammar check, and if it passes a syntax check, it tries to resolve the object name it contains, and if it does, it resolves whether the object referenced by the object exists. If the referenced object name does not exist, the resolution is triggered when the stored procedure is first executed. That is, when the stored procedure is first executed, the query processor reads the text of the stored procedure from the Sys.sql_modules catalog view and checks to see if the object name used by the procedure exists. This process is called deferred name resolution because the table object referenced by the stored procedure does not need to exist when the stored procedure is created, but only when the stored procedure is executed.
Note:
You can use deferred name resolution only if the referenced table object does not exist. All other objects must exist when the stored procedure is created. For example, when you reference an existing table in a stored procedure, you cannot list columns that do not exist for that table.
---The stored procedure deletes the intermediate table r_ldbg_b1_temp, but this does not succeed.
If object_id (' r_ldbg_b1_temp ', ' U ') is not NULL
drop table r_ldbg_b1_temp
Cause Analysis: & nbsp The R_ldbg_b1_temp table field structure changes when executing another stored procedure, causing other stored procedures to reference fields that do not exist. When the
Executes the stored procedure, it resolves, and when it finds a field that does not exist in the reference table, it will immediately error and cannot be executed.
There are two workarounds:
1) Delete the intermediate table before executing the stored procedure externally.
2) executes the final Delete intermediate table inside the stored procedure.
SQL Server creates the stored procedure without error, but executes the stored procedure times error