How to fix Error 8145 on Windows Server 2025 / Windows 11

by

Troubleshooting Guide: SQL Server Error 8145 — “%.ls is not a parameter for procedure %.ls”

Why This Error Happens

This error occurs when a stored procedure or function call references a parameter name that does not exist in the target procedure’s definition, typically due to a typo, case mismatch, or an outdated cached execution plan referencing a prior version of the procedure. It can also happen when an application or ORM layer passes a named parameter (e.g., @UserID) that was renamed, removed, or never existed in the actual procedure signature on the server. In some cases, this is caused by schema drift between development and production environments, where the calling code was written against a newer or different version of the stored procedure than what is currently deployed.

Step-by-Step Resolution Guide

Step 1: Verify the Actual Parameter List of the Procedure

  • Open SQL Server Management Studio (SSMS) and connect to the instance running on Windows Server 2025 / Windows 11.
  • Run sp_help 'YourProcedureName'; or query sys.parameters joined with sys.objects to get the exact, current parameter names.
  • Compare the output against the parameter name mentioned in the Error 8145 message to confirm the mismatch.

Step 2: Inspect and Correct the Calling Code

  • Search the client application, ETL job, or T-SQL script for the exact procedure call that triggered the error.
  • Check for case sensitivity issues if the database collation is case-sensitive (e.g., SQL_Latin1_General_CP1_CS_AS).
  • Correct the parameter name in the calling code to exactly match what was returned in Step 1 (e.g., change @CustID to @CustomerID).

Step 3: Clear the Procedure Cache to Rule Out Stale Plans

  • Run DBCC FREEPROCCACHE; (on a non-production system first, as this clears the entire plan cache and can cause temporary performance impact).
  • Alternatively, target a single procedure using EXEC sp_recompile 'YourProcedureName';.
  • Re-execute the failing call to confirm whether a stale cached plan was contributing to the mismatch.

Step 4: Synchronize Procedure Definitions Across Environments

  • Script out the current production procedure using SSMS (Right-click → Script Stored Procedure as → CREATE To) and compare it against the version in source control or the development environment.
  • Redeploy the correct, updated version of the stored procedure using ALTER PROCEDURE if a newer version with the correct parameter exists.
  • Confirm deployment pipelines (e.g., Azure DevOps, SSDT projects) are not pushing outdated .sql files to production.

Step 5: Validate Permissions and Object Resolution

  • Ensure the calling user/application has EXECUTE permission on the correct schema and procedure, since schema-name ambiguity (e.g., dbo.MyProc vs sales.MyProc) can cause the wrong procedure version to be referenced.
  • Fully qualify the procedure call with schema name to avoid resolution to an unexpected duplicate object.

Alternative or Verification Steps

  • After applying fixes, run the procedure call manually in SSMS with the corrected parameter names and confirm it executes without Error 8145.
  • If the error persists, enable SQL Server Profiler or Extended Events to capture the exact RPC call being sent by the application, which will reveal if the client is caching an old parameter list via connection pooling or prepared statements.