Category: Errors and Exceptions

Exception: The module being executed is not trusted. Either the owner of the database of the module needs to be granted authenticate permission, or the module needs to be digitally signed.

When we were trying to create a procedure and trying to execute the procedure, it was throwing an error as

The module being executed is not trusted. Either the owner of the database of the module needs to be granted authenticate permission, or the module needs to be digitally signed.

create or Alter procedure GetAGNodes
With encryption, EXECUTE AS owner

Though it was granted with execute permission with the user, we need to give the database trustworthy to be enabled. The below script needs to be executed to resolve the issue.

ALTER DATABASE DBNAME SET TRUSTWORTHY ON

Hope this helps, if there are any other related issues and resolutions, please feel free to share as a comment!

Exception: “Invalid parameter 1 specified for datediff.” in SQL Server

Problem Statement:

One of the view creation scripts in our deployment failed continuously with the below exception:

Invalid parameter 1 specified for datediff.
Incorrect syntax near the keyword ‘AS’.

The root cause of this error is as below.

FLOOR((DATEDIFF("W",ml.column1,ML.column2)+1)/7) AS aliasname

Solution:

FLOOR((DATEDIFF(W,ml.column1,ML.column2)+1)/7) AS aliasname

The change is that the datepart has been modified to remove the double quote.

Error Exception: Msg 3183, Level 16, State 2, Line 1 RESTORE detected an error on page (0:0) in database “dbname” as read from the backup set.

Recently we encountered the below issue while restoring a database. And we also observed the database has gone into “restoring” mode.

Msg 3183, Level 16, State 2, Line 1
RESTORE detected an error on page (0:0) in database “dbname” as read from the backup set.

The message is clear that there is something wrong on the backup set. There could be many issues related, but most likely reason would be the backup file would have got file corrupted.

You would likely to take a fresh backup and try with restore and in most cases it works good. So, the take away is “we should always validate our backups”. This is exactly what Paul S Randal explains with a survey and more details as here.

See Also

How to recover restoring database in SQL Server

How to recover “Recover Pending” database in SQL Server

If you enjoyed this blog post, feel free to share it with your friends!

Error Message: “The database could not be exclusively locked to perform the operation.” in SQL Server

Recently we encountered an error message as below while doing a rename database. So, let us look at the steps that we can use to overcome the issue with this post.

The database could not be exclusively locked to perform the operation.

We were trying to rename a database in one of our lower environment as below and ended up with the error message.

ALTER DATABASE dbname MODIFY NAME = dbname_new

Steps to resolve

  1. Take the database to single_user mode
  2. Rename the database
  3. Take the renamed database to multi_user mode

Script

ALTER DATABASE dbname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE dbname MODIFY NAME = dbname_new
GO
ALTER DATABASE dbname_new SET MULTI_USER WITH ROLLBACK IMMEDIATE

If you enjoyed this blog post, please share it with your friends!

Warning Message in SQL Server: “Database name ‘tempdb’ ignored, referencing object in tempdb.”

Today, let us quickly try to understand an error message as below.

“Database name ‘tempdb’ ignored, referencing object in tempdb.”.

Many of us would have got this message (I do prefer to call this as a warning message, not error message), however, we would not have noticed as it is not causing any fatal results. With this post, I would like to share my thoughts and like to have your views on this as well.

Let us first see when would you get this message?

use tempdb
GO
create Table #Temp_Table(Col1 int)
GO
Select * From tempdb..#Temp_Table

Now, interesting thing, when the query is changed a bit as below, the message is vanished.

Somehow, I was not convinced the above method as a solution, because that was actually against my understanding of 4 part naming convention (servername.databasename.schemaname.objectname). So, we further tried to test with few more combinations to understand how it works internally.

A simple query as below showed #Temp_Table is created with dbo schema.

As next step, tried to create a schema and a new object is created. If you look at the schema of the object, we can clearly see that it is associated with dbo schema not the new schema. That means, the objects created in tempdb database is always creating in dbo, not in any other schema. In fact, the schema part is actually ignoring for temp tables.

create schema testschema
GO
create Table testschema.#Temp_Table10(Col1 int)

Points to ponder

There is NO need of specifying schema for objects created in tempdb database.

Even we specify a schema name, SQL Server simply ignores the schema part.

If you enjoyed this blog post, please share it with your friends!