If the correct fix doesn’t work, look at the permissions (Microsoft SQL Server)

Sometimes the most time-consuming part of fixing a bug occurs after you’ve figured out how to fix it. Let’s say, for example, that you pinpoint the cause of a problem to a line of code that calls a certain stored procedure. To avoid causing other parts of the application to fail, you decide not to disturb the existing procedure. Instead, you create a new one for the specific line that doesn’t work. You implement the fix and then test it out. The behavior is exactly the same as before. You’re tempted to tear your hair out!
A common reason for this sort of scenario is forgetting to set the appropriate user permissions to the object you created. You can manage these permissions by exploring the properties of your object in the Enterprise Manager or SQL Server Management Studio. Generally, examining the permissions for other similar database objects will tell you which user account the application is using.

So repeat ten times over: If you created an object, set the permissions! Remembering this simple principle may save you hours of frustration.